Hacker News Reader

Comment by amenod | Hacker News Reader

I agree that the way modern JS (need to?) download half the Internet for a semi-useful app is annoying, wasteful and dangerous.

However, I still remember the hell that was updating the state and keeping the rendering in sync with it when using jQuery. Native JS of course doesn't improve on that, and (judging by the description - no experience with it) Alpine.js doesn't either. For me, the paradigm of rendering from the internal state is what makes React (and Vue,...) useful. Too bad that npm ecosystem sucks and that everyone is inventing new shiny useless new things all the time... But React makes non-trivial single-page apps possible.

Of course, if you need server-side rendering (for example because of SEO) then the equation changes, and maybe using Alpine.js makes sense.

View on HN

That internal state is a burden on small teams though - you're efectively implementing the persistence layer twice. I'm totally onboard for SPAs as an option when breaking down an organization, or for solving a particular kind of problem.

But they're just not worth the effort for a form-oriented website with a small-medium team behind it. Almost everything about a web-app is harder with an SPA.

> However, I still remember the hell that was updating the state and keeping the rendering in sync with it when using jQuery. Native JS of course doesn't improve on that

I think this varied a lot depending on how teams approached it and that a lot of the appeal to something like React, Vue, etc. was simply that there was one way to do it.

The approach I've been quite happy with is to use JavaScript classes (IE11 is less than 1% of global web usage) for internal state, where you follow standard practice for having ownership and updates between different parts of your app, and the HTML5 data APIs for the public elements which are managed by different codebases. Web Components has something like 95-97% availability these days but this can be as simple as using element.dataset.whatever as needed. React is definitely good for huge apps but a significant fraction of the web sites I use are solidly in the level of functionality which in 2021 doesn't need functionality outside of what a modern browser provides.

Keeping all state server side is a completely reasonable approach. The 37Signals guys have been advocating for it since 2006 or so and as long as you have a low latency connection to the server then it usually works great.

What doesn't work well (and what tended to happen with jQuery apps) is having state both on the client and on the server and having to coordinate between the two. My personal preference is for client side state with a lighter setup than React (i.e. Svelte). I like the predictable latency and I feel you don't run into a complexity barrier (e.g. multi-step forms) as the app grows.

> Alpine.js doesn't either

While it won’t fit the needs of a complex app with dozens of components, it does drive the UI from the state. In fact, it uses Vue’s reactivity engine.

I was very good at making reliable apps and managing states manually in the jquery days. Having a scaffolding helps overall and in many ways, but now in the dense jungle that is the JS "ecosystem", there is sometimes a productivity loss searching for "the right way to do X in framework Y" or troubleshooting underlying tools instead of just writing the code to do the thing. Easier, maybe, but not at all satisfying.

I think the trick is, that state needs to be carefully considered at an overall systems level, not just client vs server. That's quite hard, so many (most?) devs don't do it. Certainly, I've seen state managed well using jquery, and even vanilla JS in the ES5 era, so frameworks don't make it possible, it's always been so.

So the question is, do frameworks make it easier? I don't think they really do. I think they make it easier to manipulate state, but not designing your system will still mean state being mismanaged.

Reply on news.ycombinator.com