| ▲ | maelito a day 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. |
|
| ▲ | skrebbel 21 hours ago | parent | next [-] |
| > 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. |
| |
| ▲ | webstrand 21 hours ago | parent | next [-] | | 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. | | |
| ▲ | recursive 19 hours ago | parent [-] | | 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. |
| |
| ▲ | rimunroe 21 hours ago | parent | prev [-] | | > pedantic docs Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry. | | |
| ▲ | iammrpayments 12 hours ago | parent | next [-] | | 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 | | |
| ▲ | rimunroe 11 hours ago | parent [-] | | 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? |
| |
| ▲ | skrebbel 21 hours ago | parent | prev [-] | | 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. [0] https://react.dev/reference/react/useEffect | | |
| ▲ | rimunroe 20 hours ago | parent [-] | | 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... |
|
|
|
|
| ▲ | CharlieDigital 21 hours ago | parent | prev | next [-] |
| 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
If you want to "feel" this for yourself, here are a series of JSFiddles:- 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... |
| |
| ▲ | pverheggen 21 hours ago | parent | next [-] | | 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. | | |
| ▲ | CharlieDigital 14 hours ago | parent | next [-] | | 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. | |
| ▲ | b_e_n_t_o_n 18 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | auxiliarymoose 16 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | mrits 21 hours ago | parent | prev [-] |
| [flagged] |
| |
| ▲ | yladiz 21 hours ago | parent | next [-] | | Next time I would recommend to just wait until you’re less emotional and respond then. Your comment now doesn’t really add anything to the conversation, whereas one with a level head might. | | | |
| ▲ | jonny_eh 19 hours ago | parent | prev | next [-] | | I make myself less emotional about internet comments by first assuming they're all written by bots :D | |
| ▲ | skrebbel 21 hours ago | parent | prev [-] | | HN has a button exactly for that! | | |
| ▲ | rendall 21 hours ago | parent | next [-] | | Enh. That button is often used for "your post gives me bad feelings" but it's supposed to be for "your post is bad for the community" | | |
| ▲ | sarchertech 18 hours ago | parent [-] | | Go read pg’s comments on downvoting. HN has always been fine with using downvotes to signify disagreement. | | |
| ▲ | rendall 3 hours ago | parent [-] | | > Go read pg’s comments on downvoting. Hmm. That sounds an awful lot like "It's true! Google it!" |
|
| |
| ▲ | scotty79 21 hours ago | parent | prev [-] | | Which one? Maybe there should be "reply later" button that would keep the spot for your future comment so you don't lose track of it? | | |
|
|
