>That's true, but state management became such a big problem because of the trend of SPAs and fat clients.

I find it strange that so many developers struggle to maintain the state of a page. Then they turn to "magic" frameworks to handle it for them. What's wrong with having a canonical Object or other data structures to represent the state? Why would anyone want a generalized framework to (mis)represent the core model of your application?

We've been creating applications with internal state for decades now. GUI applications with an internal state existed before the web. Typically it is achieved via code hygiene and sane abstractions. As an example, the template element keeps your document structure out of your logic.

Yet in the modern JS world, display, state and now even the backend are all shoveled together into an unmanageable monstrosity. From this point, even more magic is added to duct tape over the madness. As a result, the accepted norm is now 10mb of cruft to display a static page.

▲

troupo 20 hours ago | parent [-]

State was never easy. GUI apps have struggled with this as well. Hence you have the proliferation of different approaches: MVC, MVVM, various attempts at streams and observables, state machines, flows... All of these came from outside the web world. And, as most things in the web, all these concepts either arrived too late, or couldn't be implemented properly for various reasons.

And the problem is exacerbated by the fact that people are trying to push native app paradigms onto what is still a document-rendering system. So where you can have thousands of objects rendered at 120Hz on a mobile phone, the web struggles showing and animating a few hundred nodes even on a desktop computer. So you have to think of all the machinery to change as few DOM nodes as possible.

As for the difficulty...

The difficulty usually comes from people mixing up two concepts: the state of data, and the state of the UI.

E.g. while a music player should present data on the currently playing song (state of data), there's a few other things that are UI-only. E.g.: there's a timer running on when to hide the controls (that has to be reset/disabled when a button is pressed)

	▲	palmfacehn 19 hours ago \| parent [-]
		>GUI apps have struggled with this as well And when we made mistakes there, it was usually because we took short cuts instead of respecting clean abstractions. >So you have to think of all the machinery to change as few DOM nodes as possible. This is where I get off the train in regards to JS frontend frameworks. We should know the state our data. We should also know the state of our display components, whether they are canvas elements rendering more complex data or mere tables. KISS principles apply here. "All the machinery" of a framework isn't necessary to handle the synchronization between the two. Especially when it mandates ridiculous build steps, thousands of dependencies, opaque "magic", huge blobs of minified JS and loading spinners. >The difficulty usually comes from people mixing up two concepts: the state of data, and the state of the UI. Agreed 100%. Which is why I like the <template> element. It is a dose of sanity allowing explicit separation of code and document. I suspect this is the other poster's objection to HTML inside of JS.