I know posts like this get a lot of whinging, but you are 100% right. The browser is in itself a platform; frameworks are not like some kind of hyper abstracted Web Scrinting Language for people too important to deal with "raw" CSS/DOM. They're a an awkward, alternate abstraction, slow as molasses, and they leak like a sieve.
Why Vanilla JavaScript
51–60 of 176 posts
Re: Why Vanilla JavaScript
#52So many more problems solved… Those problems aren't 'solved'. The author has an implementation of a solution. It's one that they think is good, which is ace and I'm happy for him, but if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is…
yes it's still a framework, duh. it's just less abstraction than react etc.
Re: Why Vanilla JavaScript
#53But in response to the article: no, vanilla JS is a nightmare to keep your code organized, and battle tested frameworks do quite a good job at that. It's otherwise mostly a waste of time, or an intellectual exercise at most, to build an app with vanilla JS
Re: Why Vanilla JavaScript
#54I wish there was some sort of "use strict-typed" or something that let you use in-browser interpreted typescript
Well, you could use jsDoc to hold your types instead of writing them in typescript. The typescript compiler can still check types in jsDoc comments but you do not need a build step and the javascript you ship to the browser would be the same you write in your editor.
Re: Why Vanilla JavaScript
#55What’s the Idiomatic Vanilla JavaScript way to bind data and UI in a web browser?
IMHO knowledge of C++, Python, or pretty much everything that's not a lisp variant, doesn't translate well to JavaScript.
There's such a nice language with its own silly warts, readily available to pretty much anyone with a computer regardless of form factor, being misunderstood by the vast majority of programmers.
Re: Why Vanilla JavaScript
#56So many more problems solved… Those problems aren't 'solved'. The author has an implementation of a solution. It's one that they think is good, which is ace and I'm happy for him, but if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is…
you just agree on a set of conventions for components and state management, it's not that hard. This is basically how Rails works... yes it's still a framework, duh. it's just less abstraction than react etc.
Other people make different choices. That doesn't mean they're wrong.
Re: Why Vanilla JavaScript
#57Just use server side template rendering with HTMX. LLM can see server side request flow better anyway.
Re: Why Vanilla JavaScript
#58I love vanilla JavaScript. All my personal projects are plain JavaScript. No Typescript. But in a company setting, it's almost impossible to find plain JavaScript roles. Plain JS is also a lot better with AI. I don't recall Claude ever making any mistakes in terms of getting the type wrong with plain JS since I started using it. It's just not the kind of mistake that AI makes. I feel somewhat vindicated by this. I've…
Re: Why Vanilla JavaScript
#59Earlier quoted context omitted.
you just agree on a set of conventions for components and state management, it's not that hard. This is basically how Rails works... yes it's still a framework, duh. it's just less abstraction than react etc.
Sure, and if you like working with the conventions and abstraction Rails offers that's great. Other people make different choices. That doesn't mean they're wrong.
People keep touting react etc but I swear every mobile ordering app I use lags like hell, just from recent example, and these can easily be built and maintained without a huge framework to "manage state" or "connect state to the view".
Re: Why Vanilla JavaScript
#60Did I misunderstand or was that whole rant just to establish that, actually, we do need super tiny frameworks for the front end, but they're super tiny so it's not a big deal and they're not bad like React?
If that means you have to make a small thing that is designed to do just the task at hand but to do it well, I am all for it.
I think the only frameworks that I have encountered that I felt were worth using were server side things like express where they had a very specific task to do and could isolate areas of behaviour.