alt Hacker NewsI would be happy to discuss more. I am genuinely curious (though I do hold a pretty strong belief that React is a good abstraction).
When you say that the DOM is the authority on state, I’m not sure if that addresses my concern. Let’s revisit my example of the button. Image I look at the DOM and see that it’s in a “Submitted” state, and I think that’s a bug. How can I determine how it got into this buggy state? The DOM can’t answer that question, as far as I can see, because it is only an authority on the current state of the system at this exact moment. The only way I see you answering this question is by scanning every single API endpoint that could have plausibly swapped out the button for its new state - which scales at O(n) to the side of your repository! And if one API could have added HTML which then added more HTML, it seems even worse than that.
The advantage of React is that you get a crisp answer to that question at all times.
> I built multicardz on this: 1M+ cards, sub-500ms searches, 100/100 Lighthouse scores.
I believe you! But I am more concerned about readability. React makes some tradeoffs, but to me readability trumps all.
The debugging question has a direct answer: when you capture User State from the DOM (via manifest) and send it to pure functions on the backend, you get a perfect event source pattern.
Not only can I can tell you exactly who and what triggered any piece of HTML being sent to screen, I can rewind and replay it like a tape recorder.
The broader philosophical difference: I don't treat "state" as one thing. User State (what the user sees and expects to persist across refresh) lives in the DOM.
Auth state, db cursors, cache: backend concerns. Pure functions on the backend are deterministic; same input, same output, trivially testable.
I have no hate for React; I was a core member of the React Studio team. But for my use cases, this model gives me better debuggability, not worse.