Comment by maelito 11 hours ago
Rewrite the first paragraph replacing "React" by "HTML".
React is mostly HTML driven by data. "HTML killed front end innovation". Well that enabled standards to build real use cases on it with a common ground.
Before React, the Web world was a mess. In 2025, you have lots of frameworks to explore. React did not kill front end innovation at all, it just became a standard that gives more common understanding to building a website.
I thought the way React did suspense was pretty elegant?
The component render function is pure, meaning you can re-render component without unwanted side-effects. So on encountering an unresolved promise, halt and throw the promise, then have the runtime catch the promise and re-execute the render when it resolves. I thought this was really an elegant way to introduce an asynchronous dependencies.
It only achieves purity by re-defining the pre-existing concept of "pure". Component state is not passed as an argument, and can affect the output of a render function. It's only by playing semantic games that react claims to be pure, which I find to be of dubious value in this domain anyway.
This is the most pedantic section for me, it’s just a bunch of 5 year old illustrations with 0 explaining on how React actually works behind the scenes: https://react.dev/learn/render-and-commit
Sorry, what’s the pedantic part of this? I don’t think I’m understanding what you mean by that word here.
Do you mean that the information isn’t useful? This page is explaining the process React takes when rendering, the general version of which hasn’t really changed since it was released. There are differences in things like Suspense and SSR, but it’s broadly the same. Knowing the difference between render and commit phases is important for other parts of the docs to make sense.
What sort of behind the scenes workings would you want explained here?
Yeah stuff like useEffect which is supposedly a function that "lets you synchronize a component with an external system" [0]
So eg when you want to focus an input, how do you do that? That's the input itself right, that's my core UI, that's not synchronizing, it's not an external system so I'm not supposed to use useEffect for that, right? That'd be bad, no?
Turns out I do need useEffect, and in fact it's the only way, barring using 3rd party hooks or components that, themselves, use useEffect for this. And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app! That's not an external system at all. It's as non-external as things can get and I'm not synchronizing anything, I'm focusing an input.
This entire "external system" story isn't at all about what useEffect is, it's not what it does, it's merely what the React designers have decided you should use it for.
useEffect lets you run side effects. That's it, that's all there is to it. But they rewrote the docs with total beginners in mind, and put them so full of dos and donts that they forgot to explain what stuff actually does. Gaaah.
And half the documentation is like this. It dances around the actual behavior, never really explicitly saying what things do or how they work, with huge rants about what I ought to do and no info, except maaayybe hidden in some expando, about how things actually work and why.
What's the condition in which you're trying to focus that input? Usually you're doing that in response to some sort of user action, in which case the time to handle that is within an event handler.
> And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app!
External systems usually means stuff like an event system, network requests, or something else not managed directly by React. Unless you're reaching outside the area of the DOM React is managing, you can usually do this in event handlers or (for spookier cases) ref callbacks. There are certainly exceptions, but it's often an architectural smell.
Further down in the docs you'll see[0]:
> Effects are an “escape hatch”: you use them when you need to “step outside React” and when there is no better built-in solution for your use case.
[0] https://react.dev/reference/react/useEffect#wrapping-effects...
Actually, React's problem is that it's the inverse of how HTML and JavaScript works in terms of how to handle callbacks. Of the major UI frameworks, it is the only one with this quality (Vue, Svelte, Angular, Solid, etc. use signals).
This inverted behavior is the cause of most of the pain and footguns in React and React Hooks because the way state behaves in a React component is not the way state behaves in any other front-end JS one would normally write.
That's why I think for some folks who started with HTML + vanilla JS, React Hooks just feels wrong. It points the reactive callback to the component function whereas every other framework/library uses some sort of signal to point the reactive callback to a handler. Because React points the callback to the component function, then you have to be really cautious about where you put state inside of a component[0][1][2]
Even You wrote this about React's design choice which I think sums it up best:
> The pain and suffer[ing] of hooks all roots from the mismatch between a dogmatic belief in the superiority of immutability and the harsh reality of the host language that is JavaScript
- Vanilla: https://jsfiddle.net/qtmkbdo2/8/
- Vue: https://jsfiddle.net/vys2rmup
- React: https://jsfiddle.net/0gjckrae/1/
It should be obvious that Vanilla and Vue behave like how one would expect callbacks to work. React, because it points the callback to the component function, then requires that you be cognizant of state inside of the component function (placement, memoization, immutability, etc.). All of the pain of React is self-imposed from this design decision.
You can read more about it here: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...
--
[0] https://adevnadia.medium.com/i-tried-react-compiler-today-an...
[1] https://tkdodo.eu/blog/the-useless-use-callback
[2] https://adevnadia.medium.com/react-re-renders-guide-why-reac...
Here is an alternative vanilla approach that uses a single-file/single-class-declaration custom element without Shadow DOM: https://jsfiddle.net/auxiliarymoose/tcgk1Ljv/98/
Usually I write a few helper functions to streamline working with elements, attributes, and registration of element + CSS. But even without those, I think this approach provides a good level of simplicity without introducing libraries or frameworks.
Technically in React, the reactive callback is still the event handler. It's a two-step process where your event handler is evaluated first, then re-evaluates the component tree which changed as a result of the handler. In your JSFiddle example, if you modify `onChange` to print a console log instead of setting state, you'll see that it doesn't run the component function again.
So really, the key difference between React and Vue is that your function component is not the setup, it's the template.
I don't know if I'd consider that the reactive callback because there's no change in state if I only put the `console.log` in `onChange`. The point of the reactive callback is to be invoked on a change in state and in this case, that is the component function would you agree?
In Vue, for example, when I set up a `watch`, the change in state only invokes the callback that is wired to the state. In React, the entire component function is invoked again on a change of state.
Yeah that's a pretty good way of putting it. In Vue et al, the script tag is a constructor and the template is a render function. In react, you just write a render function and use hooks to define stuff that otherwise would have been in the constructor.
Go read pg’s comments on downvoting. HN has always been fine with using downvotes to signify disagreement.
> React is mostly HTML driven by data.
I wish! Mostly though, React is a terrible mess of hooks with weird rules, suspense, “use client”, pedantic docs, and millions of other idiosyncrasies that have no business being this mainstream.
I think most people agree that the core ideas are great. Eg composable components, props, unidirectional data flow etc. There’s a reason that all other reasonably popular frontend frameworks adopted these ideas. It’s great that React established them. It’s just a bit sad that React established them.