111–120 of 553 posts
A side issue, but... can anyone tell me why people say "the orange site" instead of just saying Hacker News, as if it is a bad word or a secret?
I’d love to know who started using it first, though.
> It is not obvious that your component re-renders on state updates. I... isn't it? Isn't this like the first thing in the hooks introductory material? If you don't find this, yeah, hooks are gonna be a bad time.
> Line 9: When the user clicks, we call setCount with a new value. React will then re-render the Example component, passing the new count value to it.
https://reactjs.org/docs/hooks-state.html
I think they assume you'll figure out that it must do so to function at all.
Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed…
Isn't this the whole selling point of Solid's signals? If a child component receives its props from the parent as signals, and asks the parent to fetch some data and update the state, then the child won't rerender; only the bits that are consuming the signals will. Fine-grained reactivity, they call it.
Earlier quoted context omitted.
React definitely continues to innovate. Functional components and hooks were a huge innovation to class components and significantly improved the ergonomics of the library. That was only a few years ago. The team is actively working on RSC (react server components) which will have a similarly large impact on react's capabilities. Frameworks like remix and next will be able to leverage and build on this to create even…
All blow up events come from a loud and extremely small minority. But whether they are making noise or signal, does not depend on number of people! React continues to dominate others because it meets baseline criteria for a js framework. And has corporate backing while Vue doesn't. Angular 1 was also popular because it was average js framework with google's backing before angular 2. Implying that React remains popula…
React is not perfect, it's bloated, but the reason it took off is that it brought something new to the table as a general and programmatic way to construct UIs. Being a child of Facebook helped it achieve dominance but considering that before React we had angular (shudder) and jquery, React's success was well earned.
React will be replaced when something actually better comes along. The current contenders seem to want to return us to the technology of the past, it didn't work then and it doesn't work now.
As a more backend guy who does some frontend, the main thing I like about React over alternatives like Svelte, Vue and SolidJS is React Native. React is maybe not perfect for the web, but it’s very, very good, and it’s also quite good for mobile via React Native. The more purely web-focused libs/frameworks have far inferior (or no) mobile options, while other cross-platform frameworks, like Flutter, suck on the web.…
I'm using React Native to build mobile games, and I am pleasantly surprised I can just write my own state management and update logic (hack around states and props) to walk around a lot of issues and get good performance.
Earlier quoted context omitted.
The bit of react that is f ( newState ) => UI is the easy part. The bit that is g ( state , userInput ) => newState is the hard part. In particular managing the scope of that newState . Oh, and sometimes you need to handle h ( state , asynchronousData ) => newState too. And then comes the fact that even though your f is _pure_, it also has to be _fast_, because it's going to run every time you get a newState .
I get so lost in these conversations, because I've been the lead on a relatively complex React app for literally years now and none of any of this has mattered or come up in any way whatsoever. Our app is plenty fast/responsive, maintenance hasn't been perfect but it's been manageable, same with new features... The learning curve around context was a bit steep but we get it now and haven't had any issues since. It's…
When I do encounter a component with countless re-renders as described, it is usually painfully obvious what causes them and easy enough to fix.
I think we're going too far if we're expecting React, or any framework, to be fool-proof to the point that we can just throw "whatever" we want at them and expect it to have peak performance.
As a more backend guy who does some frontend, the main thing I like about React over alternatives like Svelte, Vue and SolidJS is React Native. React is maybe not perfect for the web, but it’s very, very good, and it’s also quite good for mobile via React Native. The more purely web-focused libs/frameworks have far inferior (or no) mobile options, while other cross-platform frameworks, like Flutter, suck on the web.…
I don't understand this quote from Tanner. Aren't React hooks, like, the only way to tell a function React component (while inside of it) to re-render? And if you look at the code of, say, the useBaseQuery hook of tanstack-query, you will indeed find React's native hooks being used there [0].
0 - https://github.com/TanStack/query/blob/main/packages/react-q...
Earlier quoted context omitted.
The bit of react that is f ( newState ) => UI is the easy part. The bit that is g ( state , userInput ) => newState is the hard part. In particular managing the scope of that newState . Oh, and sometimes you need to handle h ( state , asynchronousData ) => newState too. And then comes the fact that even though your f is _pure_, it also has to be _fast_, because it's going to run every time you get a newState .
I get so lost in these conversations, because I've been the lead on a relatively complex React app for literally years now and none of any of this has mattered or come up in any way whatsoever. Our app is plenty fast/responsive, maintenance hasn't been perfect but it's been manageable, same with new features... The learning curve around context was a bit steep but we get it now and haven't had any issues since. It's…
Timing-based UIs are (such as a sequence of triggered animations) can get really messy really fast. I've seen some really messy bugs in a app that had visuals and audio tied to different timers and user inputs in the app. We eventually moved all time-based animations to observables, which helped some
Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed…
> I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. Isn't this the whole selling point of Solid's signals? If a child component receives its props from the parent as signals, and asks the parent to fetch some data and update the state, then the child won't rerender; only the bits that are consuming the signals will. Fine-grained reactivity, they call it.