[austin-cheney]

Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.

[skydhash]

State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.

[austin-cheney]

What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.

[skydhash]

Reactivity is just one pattern to help manage state. We have observable (which is just reactivity in another cloth), Entity-Component, View-Model (also Presenter), etc,…

[joquarky]

Ever use knockout.js?

I think it had/has the perfect balance of utility without being overly opinionated. State was also much easier to deal with.

I haven't used it in a while, but still look back on that project fondly.

[mr_toad]

React isn’t about persistence between page loads. React is about declaratively declaring two different page states and “diffing” them so that only the diffs are applied to the DOM.

Storing the diffs to local storage is an interesting idea though.