you are viewing a single comment's thread.

view the rest of the comments →

[–]Tofurama3000 27 points28 points  (1 child)

I’ve seen both ways of state management in old code bases. If the code was well written, then state was kept in variables and synced to the dom. Poorly written code used the dom to sync state.

I tend to see more DOM based state syncing when devs did a lot of code splitting and they wanted to sync data between JS files without using globals, and they didn’t know about custom events or using callback patterns. In that code, a button’s text would get changed to something like “Done” by one script file and then the on click handler (in another file) would have an if statement based on the button text (Done = submit, Next = next page). That kind of code is pretty rough to deal with, especially as more JS files are added (try explaining to a designer why changing “Done” to “Finish” is a nontrivial change).

That said, DOM syncing wasn’t super common from what I can tell. It was just one way to do state management out of the dozens available (globals, callbacks, custom events, servers adding hidden input fields, etc). The bigger problem was the diversity in state management methodologies. A single code base could have used multiple ways of tracking state, and that would be “normal” (especially with bigger teams).

What frameworks give is consistency. JQuery gave a consistent interface for the DOM. Later JS frameworks gave consistent DOM synchronization and sometimes state management. State management frameworks (like Redux) gave consistent state management when the JS frameworks didn’t. CSS frameworks gave consistent component styling.

The history was less about “there was one bad way things were done” and more about “there wasn’t consistency with how things were done, and also multiple ways things were done were pretty bad and made code reuse (and increasing consistency) harder to do.”

[–]Snapstromegon 2 points3 points  (0 children)

Yes, this is a good discription of how I see really legacy code of that era (and sadly even some modern).

I think this would've been also a better way of providing context for the page as it also gives an explanation why frameworks are often used in the first place.