[continuational]

The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another.

The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you.

It's not irrational; quite the contrary.

[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.

[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.

[alpha_squared]

Svelte seems to do this just fine. It's much simpler to work with, doesn't introduce too much proprietary code, and is both lightweight and incredibly fast.