I don't understand the argument that you have to rewrite your application everytime React introduces a new feature.
My current company is using a React app, built on top of Create-React-App, and still has some class components sprinkled throughout.
We simply have simply chosen not to rewrite everything each time a shiny new feature comes along. Instead we incrementally adopt the new things as they come along. Everything works fine. Those class components are in parts of the codebase that haven't needed to be updated in years...next time I need to make more than a trivial change to one of those components I'll take the extra 15 minutes to update them to use hooks.
We are looking to get off of CRA since Vite has a much quicker build time - but we've managed to make it ~8 years before deciding this upgrade was worth our time.
We have absolutely 0 plans of migrating to a framework so we can use server components.
Same experience here, React is actually very good about backwards compatibility, and for anything that is pervasive, codemods via jscodeshift works pretty well too.
I have had to make changes to the build system for the React system I maintain at work, but in no way would I consider it a "rewrite", as much as a "refactor" for a specific part of the codebase while leaving the rest relatively untouched.
In fact, JavaScript moving to ESM has broken MUCH more code than any of the React features listed in the article.
Absolutely agree. I work on a cra-based SPA at work which might have 100s of issues, but React for sure isn't one of them. Packages exporting made-up types are. JavaScript's goofy transition to ESM is. Babel might be. In a world where a new JS framework boasts about being the future of webdev every other day, React hasn't shipped a single update in 1+ years now, and has generally been super cautious to maintaining backwards compatibility and a super easy API. The only questionable move has been the unnecessary push to server components, but imho that's more of a political problem, since vercel has eaten up the react team and has this weird habit of trying to sell terrible architectural decisions to its users.
Same. I've spent a good part of the last seven years working on and around a large React app, and it's been fine in exactly the ways you describe. I've got my complaints and maybe I would spare half a thought to considering another library if I started a completely greenfield app, but over all I'm very happy with what React has given us – especially over what was around before.
My current company is using a React app, built on top of Create-React-App, and still has some class components sprinkled throughout.
We simply have simply chosen not to rewrite everything each time a shiny new feature comes along. Instead we incrementally adopt the new things as they come along. Everything works fine. Those class components are in parts of the codebase that haven't needed to be updated in years...next time I need to make more than a trivial change to one of those components I'll take the extra 15 minutes to update them to use hooks.
We are looking to get off of CRA since Vite has a much quicker build time - but we've managed to make it ~8 years before deciding this upgrade was worth our time.
We have absolutely 0 plans of migrating to a framework so we can use server components.
The app makes lots and lots of money.