Hacker News Reader

Comment by SeanAnderson | Hacker News Reader

Didn't React 19 introduce a compiler in an attempt to provide auto-memoization? That feels pretty substantial.

The fact we got to a point of auto-memoization on every reactive function is crazy to me. How is that not prematurely optimizing? I already saw people doing useMemo on shit that shouldn't be getting called repeatedly with the same value. So maybe it is better to let a compiler decide, although I am curious how it knows.

EDIT: if its pure (not reactive to any other variable but other variables may react to it) they will auto memoize I guess to avoid their own reactivity engine doing a bunch of useless shit when no value was actually updated. Correct me here if I am wrong.

It automemoizes objects that would otherwise be recreated on each render, which would then cause rerenders down the tree. By memoizing these objects, they reduce the amount of rerendering done without actually changing the semantics of the code you write (unless you wrote code that only works because of frequent unnecessary rendering).

Just to clarify: despite its name, React has no reactivity engine at all and re-renders unconditionally on any state changes or parent re-renders.

You have to opt-in to prop-diffing conditional re-renders (which I wouldn't call a "reactivity engine" either) per component, via React.memo.

And then you also have to opt-in to prop memoization for non-primitives for the prop-diffing not to be useless.

These re-renders might not result in any actual DOM changes since there is an additional vDOM diffing step from the resulting render (which, again, I wouldn't call a "reactivity engine").

I am probably just misguided but multiple things you say you "wouldn't call a reactivity engine" only exist to support updating DOM (reactivity) efficiently. So what would you call them? They only exist to update the DOM, which is itself the reactivity we all want. Technically you could just getElementById and update it, but react has what I call a whole "reactivity engine" to do it for you.

It might be more useful to think of React as having a very simple reactivity system. In essence it just compares state values by referential equality (===) and if they're different, rerenders the component. And that includes children. In order to optimise, you need to both maintain referential equality of objects across renders (i.e. don't recreate them each render) and then tell React to compare the props passed into components by said referential equality before rendering.

Whereas other frameworks have a full blown reactivity system with signals (basically implicit observables), so your state values are not just regular javascript objects but either proxies or some other object which can be tracked by access in components to update things granularly, eg. setting an elements innerText but automatically.

Reactivity has a specific meaning in programming:

https://en.wikipedia.org/wiki/Reactive_programming

https://en.wikipedia.org/wiki/Functional_reactive_programmin...

Which I think React doesn't really fit. React is not about data streams, nor about inferred dependencies.

> Technically you could just getElementById and update it, but react has what I call a whole "reactivity engine" to do it for you.

I would call that "declarative", not "reactive".

https://en.wikipedia.org/wiki/Declarative_programming

The closest thing to reactivity React has are dependency arrays in `useCallback` but I'd say it's a stretch to call that reactive programming.

Compare it with SolidJS's data flow. https://docs.solidjs.com/ Also notice how "reactive" is all over their landing page while React doesn't mention "reactive" at all https://react.dev/

Reply on news.ycombinator.com