What does churn is the tooling (e.g. abandoning Webpack for Vite). But the actual API and syntax has remained virtually unchanged. You can still write and use class components today. Hooks themselves are nearly 7 years old at this point, with no sign of changing. You are not required to use "server components" or any of the new features in React.
Meanwhile people in this thread recommend "simple" alternatives like Vue that produce breaking changes so massive it splits their ecosystem in half.
It's a form of technical smugness that pervades this site for any frontend JS thread.
You rarely see frontend devs criticise backend devs on their tech stack.
If you use just React I'll support you until the end of time but haven't seen a shop yet that does. I'm not saying use HTMX, if you have the choice go with just React over HTMX because it's still in flux.
Just React << HTMX < React with Friends.
It's the advice from POODR that's stuck with me forever, an objects dependencies should change less often than the object itself.
It's just not true in my experience.
FE tooling is never a one-size fits all thing like Postgres, but people want it to be (god help you if you have 2 different FE libraries that serve different usecases, even though 90% of the time you just need simple tooltips or a multi-select box that play nice with static server HTML) and the cost is giant, unmanageable, extremely expensive piles of JS where the entire frontend is pushed inside of it.
I think the web technology and the kits that sit on it are rather obtuse because they really are swimming against the tide. I commented about VB a few weeks ago and how much better the paradigm was some 30 years ago. But that was a purpose-built tool for programming a purpose-built GUI API. React et al. are still contending with turning typesetting into general purpose software. Despite that, react does a pretty good job.
It's also about know-how. I can go get a programmer literally anywhere that can built something with react, so even problems that can be solved without are going to be solved with it.
No complaints from me, really. Everything is a little excessive. I just came across an app to order ice. I can't imagine that's really making anyone's life easier, except for maybe its developer.
1. Beyond self-learning, there's two types of education. Formal, college education that delves deep to both the CPU level and mathematical proofs of correctness, and coding bootcamps which teach how to do things, but little about how things work.
Frontend isn't taught in formal college education, so there's a big void in industry knowledge. Some people learn about compilers, interpreters, have used GDB and implemented malloc for school, but they aren't the ones doing frontend. Others are doing frontend but never think about memory usage, closure scopes, or garbage collection.
This leads to bad frontend code, that misuses resources.
2. JavaScript long had fame for being a "toy" or "joke" language. I noticed the tide slowly change by the mid 2010s— that's not that long ago.
Proportionally and compared to other technologies, how many engineers have had time to develop long careers, learn from mistakes, and become that serious, dress-shirt wearing, super-senior engineer sitting at the back of the room making sure young developers don't get too unhinged? This proportion is probably especially stark if you consider just how in-demand web development is.
This leads to bad frontend code, that misuses resources.
3. Finally, with the two above in mind, re-writes. Unexperienced teams are the first to opt for re-writes. It's a story as old as time; "we don't know how to fix A, so let's instead build a brand new thing B, which works differently to A and thus won't have its problems".
Re-writes always go well at first, because the fresh codebase will be smaller, faster, nicer and because everyone is especially cognisant of the problems A had, which are very much not present in B since it works differently.
Eventually of course, B grows bigger, and gets permanent hot-fixes, its requirements change, and bugs start to surface that nobody bothers understanding. A is also far enough in the past that nobody is thing about the problems A had anymore, and has more mind-space to notice the problems that are unique to B.
But before that happens, you get this sort of comments.
One example from my own experience was a team that inherited a service that had already seen a major rewrite/refactoring to be prepared for requirements that the old team knew with certainty was coming. The new team created a new service that barely covered the needs that the company had at the time, and claimed that the new architecture was flexible to cover any future need (without actually investigating the needs that were already known). When they were tasked with supporting the new requirements, the end result was more complicated and less capable than the old service.
And React is worse than the alternatives. All it has going for it is the huge ecosystem.
