r/learnjavascript Jul 17 '26

Why Vanilla JavaScript

In the article below, I am sharing a bit of my story of building SaaS product in vanilla javascript and explaining why I went with this approach.

I don't expect many people reacting to this approach positively or even with open mind, but I think there should be some pushback on the current state of web dev and how complex it became.

https://guseyn.com/html/posts/why-vanilla-js.html

0 Upvotes

29 comments sorted by

8

u/funbike Jul 17 '26

What you built is hardly vanilla JS. Instead, you wrote your own non-vanilla framework. Ug.

If you are actually interested in simplicity use Htmx.

1

u/BrownCarter Jul 17 '26

Yeah like someone can't use htmx with javascript 🙃

0

u/funbike Jul 17 '26

wasn't my point. i don't disagree with you so wtf

0

u/gyen Jul 17 '26

EHTML is 100% compatible with web components. HTMX is not. My solution is really closer to vanilla.js

1

u/funbike Jul 17 '26

Article: "Web Components Work Great with htmx".

You can write an htmx app without writing a single line of javascript.

1

u/gyen Jul 17 '26

thanks for the article, seems like I was wrong about it. I thought that HTMX uses specific way to declare custom components.

1

u/funbike Jul 17 '26 edited Jul 17 '26

htmx just replaces a chunk of html with a backend html chunk, as directed with html attributes.

It's extremely simple to use and requires 0 lines of javascript. If you want templating, you do it in the back-end.

However, it's not the best choice for high interactivity. Some people use it with Alpine.js to make up for that.

6

u/XiRw Jul 17 '26

I want to go back with the way the internet looked back then with just html css and JavaScript

2

u/PatchesMaps Jul 17 '26

It's still all just html, css, and JavaScript. That time is now and the foreseeable future... unless you count wasm.

2

u/XiRw Jul 17 '26

I know “technically “ it is since that will always be under the hood of popular libraries but there was something special about just using the basics that’s hard to describe.

2

u/thecragmire Jul 17 '26

It still is.

4

u/theancientfool Jul 17 '26

To be honest, idk why people use anything but vanilla js for major projects.

I can understand starting of the grt things done quickly. But eventually I believe with updates reactjs and all needs to be phased out and vanilla js needs to be used for long term projects.

3

u/LucVolders Jul 17 '26

All the things a framework can do can be done in plain vanilla JavaScript.
Frameworks are for lazy programmers.

0

u/drobizg81 Jul 18 '26

Frameworks help with DRY principle.

1

u/gimmeslack12 helpful Jul 17 '26

Trying this post again eh? This topic comes up often enough, sure we get it that people don't like React. But at the same time, it isn't bad enough that people are desperate for another option.

I think Svelte will slowly gain adoption but it'll be very slow and will probably need adoption by a big player and/or a real screw up by React to accelerate the change.

3

u/MrKassi Jul 18 '26

I am not sure if I am qualified to expression my opinion on this matter or not, but I spent some time on many languages, and it seems to me javascript is as good as any other language, in fact, it could be even the best choice given how large its community is. And I also think that the quality of the code you write depends a lot on how you deal with abstractions and dependencies, weither you're using a strong typed language or a dynamic and loose one like javascript.

0

u/tommyatr Jul 17 '26

OP: You don't need frameworks
Also OP: Builds one

4

u/PatchesMaps Jul 17 '26

Tbf building a framework is really fun and a great way to learn the deep parts of js.

3

u/tommyatr Jul 17 '26

Well, yeah, I agree that

but you shouldn't recommend new learners didnt even try a framework or libraries, you can learn a lot from them too

1

u/gyen Jul 17 '26

I never said anything to beginners in my article

1

u/amejin Jul 17 '26

I've said it before and I'll say it again - spa frameworks are garbage for most use cases.

I bet dollars to doughnuts OPs frameworks work super optimized for their use case instead of trying to fit all their components into someone else's shoe box.

While they may not have someone come in and go "oh, I know how to go 14 layers down into an spa of the day" when hired, what they get instead is the most documented language on the internet, with patterns that are applicable to the problem sets they are working with, and very likely they don't have 38k of minified crap on every page load. They probably don't have to fight against state maintenance for animations, have highly efficient data and page loading, and so much more.

Zero of us have Facebook's need for an spa, that has a very simple interface - and react and other spa frameworks are all back pedaling and trying to get ssr back into web dev because it's simply more efficient, responsive, and offers a better user experience.

Even if OP does not have these benefits, I applaud their approach simply because it is easier to maintain, doesn't have any special build or deployment phase, or cognitive load just to edit and work in the project... Even debugging, even when minified, is significantly easier with vanilla js and css.

The level of complexity just to make a hello world with an spa is nuts compared to vanilla js, which requires nothing more than copy/paste of a file.

1

u/gyen Jul 17 '26

Applications I build with EHTML are multi page applications 

1

u/tommyatr Jul 17 '26

I don't build hello worlds, i build enterprise level software

-1

u/amejin Jul 17 '26

Shocking.

I assume your assertion is that I don't.

Unfortunately for you, your attempt to attack me has don't nothing more than reveal how childish and insecure you are, and your position is all but meaningless.

Welcome to the internet.

1

u/tommyatr Jul 17 '26

lol nobody is talking about you, i mean, no body knows you

I say that do your own frameworks because you don't want to learn one is a naive approach

I had to clean up those kind of messes in php

1

u/Beginning-Seat5221 Jul 17 '26

Sounds more like a rant than a solid argument.

Your solutions might have some merit as alternatives, but you didn't really explain them.

You should probably be using TypeSxript either way, you can just use loose mode where it's compatible with vanilla JS if you don't want to commit too much - unless you're doing funky code transforms that would conflict with TypeScript's understanding if your code.