Live data from Hacker News

Why Vanilla JavaScript

guseyn.com

51–60 of 176 posts

Re: Why Vanilla JavaScript

#51
Based and Vanilla JS pilled.

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.

Re: Why Vanilla JavaScript

#52
post #49

So 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.

Re: Why Vanilla JavaScript

#53
I like this article because it feels so pre-AI. This is what people were arguing about on HackerNews back in the day! How so very nostalgic it makes me feel.

But 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

#54

I 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.

JSDoc is not as powerful as TypeScript types but that might be fine for your use case. However, if you are already using tsc I don't see why you'd care about a build step, and if you care that the JS in the browser is the same as the editor, tsc can do that too without minifying and changing the JS output, merely stripping the types instead.

Re: Why Vanilla JavaScript

#55

What’s the Idiomatic Vanilla JavaScript way to bind data and UI in a web browser?

The whole thing boils down to creating objects (the constructor is built-in) and using functions on objects. Functions are objects, too. In fact, everything except primitive values are objects.

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

#56
post #52
post #49

So 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.

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.

Re: Why Vanilla JavaScript

#57
If we are going to rant like this… i’d say even most of JS is unnecessary.

Just use server side template rendering with HTMX. LLM can see server side request flow better anyway.

Re: Why Vanilla JavaScript

#58

I 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…

Same, but the article isn't about JS vs TS, it's a criticism of frameworks.

Re: Why Vanilla JavaScript

#59
post #56
post #52

Earlier 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.

To write good React you have to follow conventions, too. You can't get away from conventions.

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

#60

Did 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?

We don't need things taking control from us. Or dictating the terms for manipulating an already defined interface.

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.

Post reply on HN