[jeswin]

> I honestly think after reading 50% of the article is all about bragging knowing history.

This is why I can't read most tech articles these days. Won't get to the point without a long detour into the background of the problem; as someone in my forties, it's hard to justify the expense.

[Existenceblinks]

I kinda get him having to drag these historical UI to draw some points but ended up having no critical points for current context and title. I guess it's info for "Get in Zoomer" part but failed to demonstrate "We're Saving React". If a zoomer read that, what should they do, what's the point to get start here, and should they save React or start something new?

[cyber_kinetist]

(As a zoomer,) I know that React is designed as the way it is because it's limited by the DOM model for all rendering and user interaction, whereas for native apps you have much more freedom in terms of design space of GUI toolkits (from a completely retained model like Qt to highly immediate ones like IMGUI).

The disappointment of the article is that he talks about how the Mac OS X apps were the pinnacle of desktop applications, but he never talks about how people have achieved this. Did the Cocoa API made some special design decisions (as opposed to MFC or Qt) that enabled devs to make more reactive apps?

[Existenceblinks]

You know it well (DOM, Retained | Immediate). There's nothing to do with saving react here. Talking about browser app specially, I'd keep eye on standard like Template Instantiation and the coming up Symbol as Map's key. It's closed to the recent "Signal (reactivity)" trend. A way to update part of tree more efficiently without re-render-the-whole-thing. As long as we still use DOM, it's not going to be more revolutionary than this.

[atom_arranger]

The only possible Revolution I see is not using the DOM. JS + WASM is fast enough, the DOM is not fast enough, or good enough, enough here meaning enough for creating highly dynamic 60FPS experiences. Main issue with leaving it behind is A11Y though.