I am currently maintaining and adding to a React app started in 2016. React is fine. 9 years of decisions by numerous people that are no longer working on it, and I can still improve and update it. I can even bring in developers with no experience on the code base to change things. I would change 75% of it now, but that is not a React problem, that is a normal development problem.
React is fine, it is stable, standard, and still works for almost any use cases. There are not many JS libraries that have stood that test of time.
Writing React code is "easy" because it's what's been mainstreamed. A lot of developers now will learn building UIs with React before learning how to do the same with vanilla.
Writing good, performant React code at scale is hard because the model of how reactivity works is "inverted"[0] from how we normally think about reactive code because React points the callback to the component and thereby requiring this dance to move the state out and then back in on re-render (which it does excessively). And thus the name "hook" because you can visualize the state moving out and back on re-render.
This inversion is also why state is harder on React, why it needs the double-render strict mode to flush out issues from mis-placed state and over-renders, and why performance will always be mediocre until they change models of reactivity.
The compiler now is 2 years+ in the making and hasn't shown any signs of actually improving much of anything. The alternatives are more than just viable, they offer both better DX and better performance with perhaps the biggest gap being React Native, which may shortly be addressed by LynxJS[1]
I had my own anti react moment a few years back - started react in 2017
After spending a substantial amount of time playing the field i’ve come to realize every library, language, framework sucks and has massive quirks. The best one is the one that you are productive with, and can work through the quirks
The issues you mentioned with react compiler are not obviously unworkable quirks, but using beta technology without a full understanding how it works
I just couldn’t get into React on an aesthetic level, so I can’t speak it what it offers practically. But for the times I’ve needed to wade into frontend, I’ve had a really pleasant experience with Vue. It has a gentle learning curve and good documentation. The declarative templates and single-file components are especially nice. To me, React is the JavaScript of JavaScript frameworks and Vue is the Python (but not in adoption/third party library support, obviously).
In this case, it looks like the compiler has hoisted the console logs from the `useMemo` calls out into the main body of the function component, because it considers those to be side effects. So, the logs are still occurring. However, the actual child component output _is_ being memoized as expected.
Alternatively, you can keep using React and have access to a huge pool of experienced react developers and libraries.
React DevTools have gotten quite good; it’s not hard to catch 99% of perf issues anymore. Inexperienced devs will write bad code in any language; have your experienced devs teach them, or just don’t hire juniors.
I agree that closures in React are annoying though.
I am currently maintaining and adding to a React app started in 2016. React is fine. 9 years of decisions by numerous people that are no longer working on it, and I can still improve and update it. I can even bring in developers with no experience on the code base to change things. I would change 75% of it now, but that is not a React problem, that is a normal development problem.
React is fine, it is stable, standard, and still works for almost any use cases. There are not many JS libraries that have stood that test of time.
Writing React code is "easy" because it's what's been mainstreamed. A lot of developers now will learn building UIs with React before learning how to do the same with vanilla.
Writing good, performant React code at scale is hard because the model of how reactivity works is "inverted"[0] from how we normally think about reactive code because React points the callback to the component and thereby requiring this dance to move the state out and then back in on re-render (which it does excessively). And thus the name "hook" because you can visualize the state moving out and back on re-render.
This inversion is also why state is harder on React, why it needs the double-render strict mode to flush out issues from mis-placed state and over-renders, and why performance will always be mediocre until they change models of reactivity.
The compiler now is 2 years+ in the making and hasn't shown any signs of actually improving much of anything. The alternatives are more than just viable, they offer both better DX and better performance with perhaps the biggest gap being React Native, which may shortly be addressed by LynxJS[1]
[0] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...
[1] https://lynxjs.org/
This is an overreaction
I had my own anti react moment a few years back - started react in 2017
After spending a substantial amount of time playing the field i’ve come to realize every library, language, framework sucks and has massive quirks. The best one is the one that you are productive with, and can work through the quirks
The issues you mentioned with react compiler are not obviously unworkable quirks, but using beta technology without a full understanding how it works
I just couldn’t get into React on an aesthetic level, so I can’t speak it what it offers practically. But for the times I’ve needed to wade into frontend, I’ve had a really pleasant experience with Vue. It has a gentle learning curve and good documentation. The declarative templates and single-file components are especially nice. To me, React is the JavaScript of JavaScript frameworks and Vue is the Python (but not in adoption/third party library support, obviously).
So why is barData being recomputed? Does anyone understand how React compiler works enough to answer this?
You can see exactly what the React compiler output is by pasting the listed code into the compiler playground:
- https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJY...
In this case, it looks like the compiler has hoisted the console logs from the `useMemo` calls out into the main body of the function component, because it considers those to be side effects. So, the logs are still occurring. However, the actual child component output _is_ being memoized as expected.
"The end of tuning is stock."
https://news.ycombinator.com/item?id=41910736
Alternatively, you can keep using React and have access to a huge pool of experienced react developers and libraries.
React DevTools have gotten quite good; it’s not hard to catch 99% of perf issues anymore. Inexperienced devs will write bad code in any language; have your experienced devs teach them, or just don’t hire juniors.
I agree that closures in React are annoying though.
One size or tool doesn’t fit all. React has its pros and cons.
"It's easy to use react inappropriately so nobody should use it"
[dead]