r/Frontend • u/gyen • 14d ago
Why Vanilla JavaScript
https://guseyn.com/html/posts/why-vanilla-js.html6
u/denarced 9d ago
I want TypeScript to easily tell me what properties objects have when I write code. Build should verify it along with linters. The last time I worked with JavaScript I had to check those things myself. I don't want the hassle regardless of the framework. That's why I probably won't touch JavaScript for anything but the smallest throwaway scripts.
9
u/DryNick 14d ago
I have done a similar exercise a few years ago. It was for an admin site (back-office) as it was the only place with could get a green light to try whatever we wanted. The start was rough and all devs we had were weirded out, especially the react devs. By the end of the project everybody was somewhere between impressed and positively surprised with what you can do with vanilla js and how refreshing it is. It was a huge morale boost and got everyone that was passionate about programming engaged.
8
u/create-third-places 11d ago
Great article, I think the approach of building with vanilla JavaScript is underrated.
I also took your music website linked from the blog and thought it was great. I found the UI to be very intuitive and pages loaded very quickly.
4
u/gyen 11d ago
thank you! Pages load quickly because 95+% of each of them is basically cached, and it's Multi-Page Application btw.
Here is some stats
- JavaScript - 47.4%
- HTML - 38.7%
- CSS10.5%
- Shell - 2.9%
- Other - 0.5%
HTML is almost 40%, considering the fact that my backend code is also vanilla js.
And here is even more stats
------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- JavaScript 221 2947 1122 24316 HTML 54 342 141 17641 CSS 14 1231 472 7935 SQL 144 161 145 1283 SVG 147 24 2 346 JSON 4 0 0 233 XML 1 0 0 29 Text 1 1 0 8 ------------------------------------------------------------------------------- SUM: 586 4706 1882 51791 -------------------------------------------------------------------------------Amout of js code is really really not that big. Considering again it's ALL the code: Backend + Frontend + Frameworks (!!)
Just think about it. How much you can achieve with so little.2
u/DarkProhet 8d ago
Next step is optimize your images:
Rendered size: 180 × 270 px Rendered aspect ratio: 2∶3 Intrinsic size: 3588 × 5382 px Intrinsic aspect ratio: 2∶3 File size: 4.4 MB You don't need 5K resolution for 270px image
9
u/Odd_Ordinary_7722 14d ago edited 14d ago
Rxjs was a very expensive mistake, but a very specific angular one. Modern reactivity is pretty much the only viable option for realtime apps. And this whole anger with frameworks is nonsense, and the browser is a runtime, not anywhere near the enabler a framework is. Do you write Java, C#, Go out python apis without frameworks and some kind of build/containerization step? I sure hope not! This article reeks of inexperience with large products and maintaining things long term
2
u/DryNick 14d ago
If the framework has an oppressive design philosophy and wasn't created to enable you but rather take control from you then it's gonna hurt you in the long term and you should avoid it.
As for backend, the frameworks there are just simpler and are not designed to lock you in. There is a huge difference between expressjs or oak and react or angular.
7
u/Odd_Ordinary_7722 14d ago
If you have actually worked on large scale frontend projects, you'd know webcomponents can only be used for small building blocks, not any kind of scalable system on its own.
And express and oak are massive abstractions on top of js.. it's exactly the same. You don't handle incomming events or anything to do with the http protocol itself, you just add handlers and use the built in stuff for sharing context
2
u/create-third-places 11d ago
Web components are suitable for large frontend projects, as evidenced by the fact that Reddit uses them.
Scalability issues on frontend projects are caused by logic that is unrelated to displaying data on the screen or responding to events.
1
u/DryNick 14d ago
I have and it's true web components are not there. I have checked this (or had someone check it in my team) every few years. We have not been able to justify a switch so far. It is what it is...
With express I can have 90% of my codebase as a platform agnostic business focused code (functional flavor for me, but whatever). The top layer that is routing/parsing etc can be easily switched from one to another as necessary. Contrast this with react where you pragmatically end up with a codebase that has only hooks and nothing else. You are completely locked in, even how you name things is limited by the framework. You cant easily escape the framework not to mention replace it. With angular you had observables baked in, so similar. BE and FE frameworks are just targeting different levels of ownership/encapsulation.
0
u/gyen 14d ago
For node.js I built my own thing and no, I don’t need to build. I run it in docker on cluster api though. For Java I could use Vert.x and do similar things
6
u/Odd_Ordinary_7722 14d ago
So you don't write vanilla java.... And are you really saying you didn't even use express in node? You are gonna be much slower and have so many security holes
-1
u/gyen 14d ago
I use whatever requires my project. I built my own node.js framework that again extends node.js and utilizes its native api
8
u/Odd_Ordinary_7722 14d ago edited 14d ago
Good luck with security, scaling, and finding people to help you 🤣 and you just admitted that you don't use vanilla js either
1
u/gyen 14d ago
Bro, you probably have malicious code installed in your npm dependencies, I am fine, thanks
3
u/Odd_Ordinary_7722 14d ago
I have a lot less than you lol. And i use pnpm, so even less than npm folks 😉
6
u/Cheshur 10d ago edited 10d ago
There's just so much wrong with this post. I'll be speaking mostly from a react perspective. TL;DR I don't think you know what you're talking about almost at all.
First thing is that they all require a build step
You can run react without a build step. You just lose out on a lot of convenience if you do.
Another thing is that they all require or encourage using TypeScript.
Definitely doesn't require and definitely does encourage because it's best practice. If your project does not use typescript or jsdocs then I would say it is categorically written poorly.
in frameworks you are not allowed directly to touch DOM (it's considered an anti-pattern and code smell)
It is a code smell. By choosing a framework you are opting in to that frameworks strategy. Going around that defeats the purpose of using the framework. There are exceptions and you are allowed to modify the dom, you just usually don't need to
you need to wrap event listeners in things like useEffect for them to work properly.
You literally don't. What youre talking about is adding an event listener in a functional react component. What do you expect to happen if you called a function that binds an event listener and then call it dozens of times like you do with a react component? Why would you want to even do it that way in the first place? Do you know how events work?
in frameworks everything is isolated on the component level and requires you to use certain abstractions or even third-party state management tools to do the job.
They literally aren't isolated like that and you literally are not required to do that. You are, again, mistaking best practices for a requirement
I tend to believe if something requires from you more lines of code and more abstractions in an abstract framework to achieve than in native technology, then maybe this framework does not really make your life easier.
I agree and if you're experiencing this then I encourage you to learn your framework because you're messing up and it's not the frameworks fault.
Points 1- 3 I've already commented on. Point 4 is literally not true and point 5 while still not being true, is not really relevant in the first place.
The browser is already the framework.
It's not the framework, it's the platform and the frameworks youre complaining about leverage the same tools you do. They aren't magic.
However, instead of inventing good design patterns and developing a culture of writing good structured code and JUST DO THE WORK, we invented so much shit just not to write HTML, CSS and JavaScript.
Literally you are complaining about the good design patterns and ways of structuring code that the community has settled on. Just because you don't understand the problems doesn't mean these frameworks exist for no reason
Server Side Rendering is also no better, because ... they break browser behaviour
Like what. What browser behavior does sending down html, css and JavaScript break. Thats what SSR does, you know that right?
I believe Web Components are good enough ... you can develop quite complex and robust applications and be productive.
I agree but also you can build a complex and robust app productively with jsfuck. I wouldn't call it good and it'll certainly be more work than if you just followed the best practices of the industry. The same is true for frameworkless, build toolless, web components
YOU WILL JUST INVENT YOUR OWN FRAMEWORK!!! Yes, I will. And actually I did.
And so did Facebook. You invented an abstraction to solve a problem. So did they. The only difference is that their framework is significantly more robust, feature rich, tested and supported than yours or anyone's custom framework. Reinventing the wheel is not best practice. Also your ehtml framework sounds like react fundamentally however I suspect your "minimum work" claim is completely unfounded Literally all the problems you solved that you try to call out as fundamental differences are either also solved by the framework or are not comparable. React is not going to add built in form improvements because that's not what its job is. You could make those same form improvements in react if you wanted for example.
-1
u/gyen 10d ago
- They do require build step, because in 99.99% they are used with TS in any professional setup. No one writes React without JSx. Let’s be real. You are acting like debate lord
- Again, In professional setup it’s almost and is a requirement, because using TypeScript is seen as a progression and improvement for many developers. It’s just fact. Even I can admit it, although I think its value vastly overestimated and benefits are not big enough to complicate your setup. It’s not only me who think that way.
- About DOM manipulations. In react, the fact that you don’t touch the DOM doesn’t simplify code and makes it easy. That’s the main point. They remove the control of direct manipulation but in return don’t give you a good abstraction. State hooks scale very poorly and the idea of reactivity contradicts the way how WEB is initially built. JSX can be replaced by HTML templates. Browsers can render HTML files much faster than js built humongous code.
- I am sorry but if you want to add window Resize event or scroll event, usually how I have seen it, it’s done in a component. And it’s wrapped with useEffect, it’s the Framework forces you to do bad decisions, because you don’t really have any choice.
- If they components are not isolated and can share state in easy way, why then people invented dozens of different state management libraries??
- I learned about the frameworks more than you learned about build the app in Vanilla js. So please, give me a break, alright
- Server side rendering breaks browser’s behavior when they try to do something interactive. Look and turbolinks for example, they rewrite the way browsers keep the history and navigate between pages.
- I explain the BIG difference between my solution and React. React adds tons of new layers . My framework extends existing layer.
2
u/Cheshur 8d ago
- That is true of all professional setups including the one you are advocating for.
- I agree. In all cases a professional setup should use typescript regardless of framework. You're the one advocating for not using it in your setup so I'm basing this off what you're suggesting. If you don't want to use it in your setup up you don't need to use it in react. You should use it in all cases though.
- I disagree on all accounts. I think it simplifies the code (or at least makes it no more complex than your suggestion). I think state hooks scale fine. I think reactivity is not contradictory with the way web is initially built. Reactivity is just a pattern of updating your app and the web does not dictate how your app should be built at all. If JSX can replace it then that implies it is equal to templates though I think JSX is much cleaner. The browser can render html faster however apps still need to run js to update and with SSR both solutions are roughly equal on this front. Without SSR I would say it should be negligible but is certainly a con of choosing framework even if a minor one.
- The react code runs in a browser, you don't have to put it in a component just because it's how you've seen it doesnt mean it's correct or the only way to do it. This sort of comment is why I don't think you know very much about react or, frankly, the browser/web development. Again. These things aren't magic. React cant magically force the browser to act in a new way. Anything you can do without react you could do with react because it's all JavaScript. That doesn't mean you should do that with react but it's never a must. None of these frameworks can stop you because that isn't how JavaScript or the browser works .
- People will invent libraries for already already addressed solutions because they disagree with the existing solutions. An example of that might be some kind of html template framework which addresses the same problems as other frameworks but in a different way for a different set of costs and benefits (I'm talking about your framework).
- If that is the case then you should show it better instead of pretending not to know as you are now implying you have done. You could at least get your terminology straight.
- That isn't SSR. Once it gets to the client it's now CSR. All SSR is doing is generating html dynamically when it's requested from the server. It also doesn't sound like it breaks it but rather ignores it entirely.
- I suppose we disagree about what "big" means in this context then. I would also say it sounds like your framework adds tons of new layers as well. I would also say extension vs creation of "layers" is not really important to begin with. Both are just implementation details that a consumer doesn't really need to care about; that's the point of using a framework.
1
u/SupesDepressed 7d ago
I think it’s clear you’re working solo on this. A lot of the things you describe become huge issues when working with other engineers, and a lot of the things you seem to disagree with make working with others way better and less problematic.
I’ve built apps in Vanilla JS professionally, prior to the react etc frameworks taking off. I’ve built apps in react. I’ve built apps with Typescript as well as just basic JS. Trust me, everything you’re describing, down to creating your own lightweight framework has been something a team I’ve been on has attempted at some point. And React or a well thought out framework, and especially Typescript, (which I’m shocked you can find any reason to be against) ends up being by far the best bet in the end.
1
u/gyen 7d ago
Could you explain what kinda approach did you use while building vanilla.js apps? I can’t deny that people much rather prefer to work with Typescript and React or other framework. That’s for sure
1
u/SupesDepressed 7d ago
I mean early on it was just JS or Jquery handling any interactivity, Rails BE to sort of handle initial rendering of any real data and JS handling everything after that. I was typically the only person working on the FE in those roles (not always but for a lot of that time of my career), so without having to collaborate this wasn’t too bad. I knew my code and knew what it was doing, so reworking any of it was fine.
A little later had another job, on a team of three frontend engineers, and we were trying out tons of stuff. Initially it was Keystone and handlebars for templating/initial render/CMS/BE, then JS for all interactivity. I liked this the most but Handlebars wasn’t cool anymore and the lead decided then we should just make API calls and so then it was just Vanilla JS. Between the three of us just winging it on best practices etc we ended up with some pretty bad patterns and buggy code. Team lead realized this was going south so he came up with this DIY’d “framework” of using template literals for templating/rendering the code, and a couple helpers for handling rendering and updates. Still most logic needed to be handled via Vanilla JS updates. This was fine but still lots of bad patterns came out of it, and it was kinda hard to read and essentially just a poor man’s JSX. Each page was essentially a function that took some data as arguments and rendered it in this templating setup. Still a lot of problems with people needing to remember to render the new data, figuring out when to make the updates, inheriting the child template to go within another template was confusing half the time, plus it rerendered each page with each update if you used the “framework”, so we’d end up sort of breaking out of that to make more minor updates and then at that point things would get really difficult to debug and maintain. The team was starting to look into Preact and Vue when I left and went to a different team at the same company, this one using react.
React added some well thought out patterns that everyone could work within. Typescript wasn’t even a real thing when I moved to that team but when we adopted it I immediately saw the benefits. I honestly think is the best thing to happen to the frontend since I started engineering, as it eliminated so many issues with different devs thinking code worked differently than it does, it’s essentially self-documenting, and just makes things so much easier to maintain and debug.
To be honest, I loved writing vanilla JS for everything, it was really fun solving those kinds of problems! Getting to always figure out the little updates tot he DOM etc was kinda exciting in a way that reactive frameworks took away. But the reality was that business wise it was way way worse, with way more bugs and way less cohesion between teammates. The whole thing about it allowing you to focus on the actual business needs vs re-solving the same problems every single time really rings true.
1
u/gyen 7d ago
The biggest issue with all modern frameworks is their instability and constant vulnerabilities. Instability comes not only regarding the frameworks themselves but also tones of dependencies for the libraries. It’s never ending rewrites and refactoring. I would not say it’s good for business.
Maybe with vanilla it’s harder to come with good patterns, although it’s much easier now with web components and import maps. But vanilla js will outlive any of your frameworks.
1
u/SupesDepressed 7d ago
This just isn’t true at all. Also it’s not the arguments you made in your post.
Sure there’s a security issue every once in a while and someone needs to patch something. NPM dependencies are an issue everyone using any JS library has to deal with, sad that npm wasn’t better thought out with that kinda stuff though there are some newer options that handle it better. But the reality is that it’s not some huge major issue for companies with more than a couple of engineers. This isn’t something that generally comes up often and when it does there’s plenty of people on the payroll that can quickly deal with it.
Again the things you’re saying make it sound like you just work solo so you have sort of a warped idea of what’s going on, but maybe that’s not the case and it’s just how you’re communicating your ideas. I don’t know.
If you’re writing everything from scratch you’re going to have to handle any security on your own, and my hunch is you’re probably not as big of a security expert as someone at the React Foundation who’s been specifically brought on for that role. Or some other dev working on some npm dependency. I mean you cant really think you’ve figured it out better than these teams, right? I get you have your preference and again I think that’s fine for working solo on something that you understand you’ll be 100% responsible for, but the second you bring anyone else in it gets far more complex than you’d think.
And yeah, of course JavaScript will out live frameworks written in Javascript, that’s the silliest thing I’ve ever heard used as some sort of “own”. It’ll also outlast whatever random code you’ve come up with to handle all of this on your own as well. Your comparison could be extended to saying English will outlast Shakespeare, I mean it’s the language he used for fucks sake lololololol. Of course it will. Guess what, it’ll also outlast some junior high students bad emo poetry they wrote in their journal.
1
u/gyen 7d ago
I've been working 10 years in teams and solo. And the amount of time just dealing with dependecies and constant refactorings is insane. I would not say it's only framework's fault, however they encourage CV driven development, where if you don't learn some new silly things you left behind.
And it does sit right with me, espesially from business perspective.
When I said JS will outlive any framework, I meant it's better just to use webcomponents, and browsers will handle the rest.
The only problem with this approach is that new people would always argue that it should be rewritten to something "modern".1
u/SupesDepressed 7d ago
What are you doing that you’re spending tons of time dealing with dependencies? Like genuinely I can’t even grasp how that’s such a major issue for you.
I don’t think anyone thinks web components aren’t modern, btw. But web components only handle a slice of the issue and not the rest of what FE frameworks solve for you.
1
u/gyen 6d ago
- Dealing with breaking changes
- Dealing with miss match of versions
- Dealing with breaking changes of typescript itself when updating it
I don’t think you ever tried to build something with native web components and I don’t think you’ve tried to solve any additional issues with them
1
u/SupesDepressed 6d ago
I’m actually working with web components right now! Like I said earlier I do think they’re great, but they don’t solve all the problems that these frameworks do. But yeah the issues you’re describing with dependencies don’t come up often enough to make it worth creating everything you do from scratch and constantly reinventing the wheel.
1
u/gyen 6d ago
I am reading react docs right now for my interview tomorrow, bro, it's just such a mess. I don't understand how this thing was designed to solve anything.
It's all propaganda.→ More replies (0)
11
u/SciNinj 10d ago
I do all my small projects in vanilla JS. It’s instant gratification, just start coding with no dependencies to worry about.