[romaniv]

Devs have learned not to keep state in the document, because it's inadequate for it.

Web devs have moved the state out of the document into JS variables and have been piling bloated, short-lived crap on top of those variables ever since.

If you actually keep state in the document things become rather simple. Scripts themselves become stateless and do not require direct dependencies on one another. Data can be queried across the page with CSS selectors. Many visual transformations on data can be handled in CSS as well. There is a well-developed system of events to handle interactions, which removes the need to handle user changes, AJAX and WebSockets separately. You gain the ability to dynamically examine and modify the state of your "application" simply by pressing F12 and changing things in the elements tab.

While it's definitely possible to imagine better ways of dealing with documents, layouts and so on, seeing how JS frameworks handle state makes me fear any "improvements" on this front.

[phailhaus]

Conflating presentation and data seems like a classically Bad Idea. Changes to presentation break your business logic.

[joquarky]

Your business logic should be behind a server.

[hinkley]

First Ajax/jquery app I worked on got a lot simpler and a lot less buggy when we started storing state in the DOM. It’s way too easy to miss a state shift in a toggle operation and have the UI be in exactly the opposite state from the api.

[taeric]

Agreed. The idea that moving state out of the document is a touch frustrating to me. Seemed to me that the entire point of a tree of data was to store the state as data?

[kh_hk]

so do you stringify all your state?

[romaniv]

Yes, but not in the sense of dumping serialized JSON into HTML. It ends up being represented by custom HTML attributes and their values. For example, if you need to keep track if the user clicked on some button, you might represent it as follows:

  <button i-was-clicked="false">

or

  <button i-count-clicks>

The content of the attribute becomes "1" after the first click and keeps increasing. The job of the corresponding JS code would be purely to keep track of clicks, so it would be very simple. Meanwhile, the value could be used for a variety of different tasks (including in CSS) and the exact same library could be applied to any element without any modification or writing "glue code".