2 ms·

> I hope this example shows why I'm passionately against applying memoizations. In my experience, it breaks way too often. It's not worth it. And it adds so muc

> I hope this example shows why I'm passionately against applying memoizations. In my experience, it breaks way too often. It's not worth it. And it adds so much overhead and complexity to all the code we have to read. React's complexities are almost all self-inflicted footguns created as a byproduct of its design that points the reactive callback to the component function. This design means that unlike vanilla JS, web components, Vue, Svelte, Solid, etc. where your state explicitly opts in to state changes, React requires component code to explicitly opt out of state changes (making the model much harder to wrap your head around and harder to do well). This is the actual root cause of all of the underlying complexity of React. In signals-based frameworks/libraries and in vanilla JS with callbacks, there is rarely a need to explicitly memoize. For the curious, I have some code samples here that make it more obvious: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-model-of-react https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...

PaulHoule 1y ago
React is astonishingly clever, the kind of use of functional ideas that is talked about in On Lisp [1] Comparing it to many systems like Microsoft's WPF or Oracle's JavaFX it's an amazingly simple way to implement components. On the happy path life is easy, but go off that path and you're in trouble. Visicalc had real reactive programming in 1979, all that useX stuff is a way to fake it without needing a compiler -- which systems like Vue 5 and Svelte need. Sometimes I think it would be fun to make an immediate mode rendering framework similar to React -- and given that it can take 10x or more refreshes for a page to be done rendering, it might as well be immediate mode. But yeah, I figured out the need for signals back in 2006 or so when I was working on a knowledge graph editor based on GWT and having to explain why there were "race conditions" depending on whether or not data was cached. When I got into modern JS around 2017 everything seemed worse than the frameworks I'd built for some very complex (think Figma) applications more than a decade ago. [1] Of which 80% of the examples don't really need macros
- owebmaster 1y ago
  > React is astonishingly clever To do what? Most of the times, simplicity beats cleverness. As an example, Lit + lit-html is nowadays what React was before hooks. It is faster, simpler, more fun to code.

PaulHoule 1y ago

React is astonishingly clever, the kind of use of functional ideas that is talked about in On Lisp [1] Comparing it to many systems like Microsoft's WPF or Oracle's JavaFX it's an amazingly simple way to implement components. On the happy path life is easy, but go off that path and you're in trouble. Visicalc had real reactive programming in 1979, all that useX stuff is a way to fake it without needing a compiler -- which systems like Vue 5 and Svelte need. Sometimes I think it would be fun to make an immediate mode rendering framework similar to React -- and given that it can take 10x or more refreshes for a page to be done rendering, it might as well be immediate mode. But yeah, I figured out the need for signals back in 2006 or so when I was working on a knowledge graph editor based on GWT and having to explain why there were "race conditions" depending on whether or not data was cached. When I got into modern JS around 2017 everything seemed worse than the frameworks I'd built for some very complex (think Figma) applications more than a decade ago. [1] Of which 80% of the examples don't really need macros

owebmaster 1y ago
> React is astonishingly clever To do what? Most of the times, simplicity beats cleverness. As an example, Lit + lit-html is nowadays what React was before hooks. It is faster, simpler, more fun to code.