alt Hacker NewsMaybe a decade ago there was chatter in the Purescript land about FRP in an applicative context.
There's ways you can write your code such that you _know_ that certain blocks of code are going to be unaffected by input changes, and you can then use that information to reduce the scope of changes that need to be done, with only minimal costs to expressivity.
I think with a decently smart compiler (and of course the compiler simply treating a lot of stuff in a black box way) you can totally shrink down the amount of work a client needs to do to render React components, all without changing the semantics.
Of course any performance trick might change the actual sequence of events that happen, and in particular for libs doing fancy DOM manipulation, it's easy for those to rely on React's incidental behavior in a non-spec-confirming way.
But the main point her is that you can totally get to useful improvements on a subset of your React, while still leaving the rest of your components intact
Sure, but trying to strip React of its virtual DOM is just a fundamental architectural mismatch; you can't have your cake and eat it (coarse-grained vs. fine-grained reactivity, fully dynamic arbitrary JSX vs. a templating language etc.). The point I'm trying to make with SolidJS is that it manages to keep JSX by intentionally swapping to signals and introducing primitives and control flow components to scope the compiler, whereas this forces the developer to hold all of this complexity in their heads and write in a specific convoluted way. It's like shipping TypeScript without type declarations and pitching knowing your types in your head as a feature lol.
In the first place, I imagine the subset of React code that’s static enough to compile into direct DOM mutations is so trivial that it’s not a useful optimization target.