The Business Case for Vanilla JavaScript | Hacker News Reader

The Business Case for Vanilla JavaScript

lewiscampbell.tech

6 pointsLAC-Tech7 comments

I write web front-ends for industrial embedded systems. So my experience might differ from business WebApps.

In my experience it requires a longer learning curve for the various frameworks than to simply learn the relevant Web API. My learning is very much JIT and over time I have built up a robust class library that gets my stuff done. When I get stuck ChatGPT suggests fixes that sometimes work and spare me from losing more hair.

My experience too - part of what I found is how much about how react worked I'd forgotten. But the browser itself was easier to pick up.

I think React caved in to wider adoption pressure to introduce abstractions that are intuitive on the surface level but are costly in terms of large scale complexity.

> It's "declarative" right up until you're debugging stateful hooks, or resorting to useRef, or trying to reason about when a "component" re-renders

Maybe they should have modularized the core library more and have these things be separate, because the core idea of a uniflow pattern with reactivity is good.

I think what happened, at least in frontend, is that the industry pushed away from having engineers do any design or architecting on the frontend. All of these high level patterns have been "outsourced" to frameworks, and the result usually is something that has trouble scaling and adjusting to whatever domain it's in.

Maybe they should have modularized the core library more and have these things be separate, because the core idea of a uniflow pattern with reactivity is good.

That's what SolidJS does. IE the signal implementation is completely stand alone. I feel like it's better at doing what react purports to do then react is.

* think what happened, at least in frontend, is that the industry pushed away from having engineers do any design or architecting on the frontend. All of these high level patterns have been "outsourced" to frameworks*

I don't think react patterns are particularly high level, or do they save you from architecture. Whether it's vanilla JS or react, you still have to design.

Oh I haven't looked at Solidjs yet, interesting will take a look. And yeah you may still need to design your application, but having hooks be something that is out-of-the-box pushes you into certain patterns and needs to be actively ignored to avoid its design influence. I've worked in large codebases where they make almost everything into hooks, and they start getting ridiculous, breaking composability but at the same time giving the illusion that you are making your code more modular.

I would personally never touch a frontend not written with a framework. Sounds like a terrible developer experience--especially with a team. But from reading your article, it sounds like your issue is with React itself. I would recommend you try Svelte, it sounds like what you're looking for. It's as close to vanilla js as you can get with all the benefits of a framework.

What benefits of a framework?

I think that's why I wrote this - I almost completely fail to see them.

Reply on news.ycombinator.com