In this post I'll tell the other side of the story. The parts the React Documentary failed to mention.
The recent React documentary was not a good look, but you wouldn't know it looking at the comments on Youtube. Some may refrain from posting anything critical, fearing retribution by members of the community. It's a real thing. Haters gonna hate.
An ethical way to make a documentary is to be objective, but the narrator is clearly crafting a narrative that is biased toward React. Why do we even need a narrator? Are we caught in a cult of personality? The documentary is a warped take on reality. There is no counterpoint, a complete lack of diverse perspectives, so we don't get the complete story.
Who am I to tell you anything about React? I'm not a React maintainer. I'm a web developer that used React in an enterprise org, someone who taught functional programming with React to others, implemented a large React UI library, and coded a React app. I've been developing for the web for over 20 years. At least I'm not begging you to subscribe to my Youtube channel.
What's the problem with React?
Churn
My time with React involved engineers migrating class components to functional, enzyme to react testing library, fixing issues with build configurations, tracking a multitude of dependencies, patching security exploits. Time that could have been spent coding features and enhancements wasted. The job of an engineer at a corporation isn't to merely maintain the codebase, our job is to deliver value for the business, to delivering features and bug fixes for customers.
After many months of work, React finally upgraded their documentation. If you haven't already migrated your class components to functional, you soon will because in the React docs class components are now deprecated and will be removed in a later version. This is just one example of the churn.
Several developers first learned how to code React using the help of Create React App, but probably found they had to roll their own build with Rollup, Webpack or Vite while working at a corporation. There is no mention of how to bootstrap client-side React apps in the new React documentation. Create React App is gone from the docs, probably for good reason because the project was unmaintained. React doesn't even recommend client-side development in the new docs, favoring several server-side implementations including Next.js, Gatsby, Expo, and React Server Components.
If the recommendation is now all React development should be done with a meta framework, the problem with going all-in server-side is that some front end engineers at corporations have no control over the server. I was one of these engineers. No argument could pull Java away from the stack in favor of Node.js, an often more performant tool that could have even saved the corporation operational costs. React has effectively abandoned engineers like me. We have no guidance for bootstrapping a React app solely for the client.
This is what happened to me after trying to convince others at a large enterprise organization to move some logic to the server.
This problem of valuing DX over UX isn't unique to React, other libraries and frameworks suffer from the same thing. What's possibly unique to React is revealed by that famous quote from Mark Zuckerberg. "Move fast and break things." I'm sorry, but at this won't fly at other corporations. It's not like React even gets the DX right. DX is a hot mess, especially when multiple parts of the ecosystem are ever changing.
So What?
Just because React is popular now doesn't mean it always will be. I think we already hit peak React, but haven't seen any conclusive analytical evidence to validate that, just a curve trending downward the last couple years in the State of JS survey.
The job market is heavily React, but it won't always be this way. A decade ago, before React even gained popularity, KnockoutJS jobs were a rare opportunity in a sea of jQuery. It's happened before and it's happening again.
There is a great sea change happening in web development. Several libraries are springing up to support UI component development with Web Components. Frameworks like Qwik are changing the game by removing hydration and moving a majority of work to the server. Change is happening now. React engineers rode a wild wave that is about to come crashing down.
By the way, I realize jQuery is still around. I just dipped into a codebase that uses jQuery. React will most likely be around in a decade. I'm not saying React is going away entirely, I'm saying React in ten years will be regarded like jQuery is today. The two libraries have similar faults. jQuery’s faults were a lack of framework and failure to coordinate the open source community. React repeated similar mistakes and how everyone in the community has to cope with those mistakes. It’s time to start preparing because React is in decline. That’s not to say there won’t always be novel use cases for React: React Native or even using Virtual DOM to provide an XML like interface for complex libraries like three.js. React will still be around, but not nearly as popular as it is today.
How To Cope With Change
If you hope to make it for a long time in this profession, it's time to start learning concepts outside of the React ecosystem. Make sure you learn the fundamentals that apply to every library and framework. That means HTML, CSS, and JavaScript. Go beyond functional programming to understand prototypical inheritance and Object-Oriented programming, which also have applications in front-end development. Take some time to learn new standards landing in the browsers. Learn TypeScript, because it's here to stay, whether as an extension of the language or at some point, types baked into the specification. Learn how servers work, http, WebSocket, and so forth. These fundamentals help you fix issues, contribute to open source, spur innovation.
It's time to start thinking, "OK, how would I do that without React?"
P.S. If you have had a great experience with React so far, I’m happy for you. This post is more about how engineering decisions effect a business. This isn’t an attack on your choice of using React. On the contrary, this is a warning. The ecosystem is too brittle to survive, causes too much churn for businesses that have invested in it. React is the victim of it’s own eventual demise, much like jQuery. It’s coming, so be prepared. If I’m wrong in ten years, I’ll admit I’m wrong, but have a hard time believing history won’t repeat itself with so many signs it already is.
Top comments (12)
Indeed we heard so weird things from react core team last months about React frameworks.
But 90% of new React documentation, even if CRA isn't recommended anymore, focus on front-end development. Vite and parcel now allow you to bootstrap front-end React app (with battery included : HMR, TS, ...) without bringing webpack, Babel and their friends and it's a good thing. If you take distance, doing React app has never been easier. 😉
React leadership has a history of saying things, then walking them back. Famously, they claimed Virtual DOM is faster than DOM. In reality, Virtual DOM is overhead and they had to remove any mention of that.
Yes, although this is also true for other libraries and frameworks. Vite, parcel, and esbuild work with them out of box and when they don't, the community makes it happen. I use a Vite server for developing a server-side rendered app with custom elements, for example. esbuild support is coming to Angular CLI soon, etc.
I hear you. But I really think the react devs are victims of their own misconception. They still believe that immutable state is the way to go on all fronts, and memoization will keep things performant at scale, even when the world a around them now turns to signals to achieve better results with less compromises.
The reality of complex apps showed again and again that this doesn't scale, even if you write idiomatic react code, which soon becomes unmaintainable for all the numerous dependency arrays.
Yeah, I see where you’re coming from, although I don’t blame the devs. In my opinion the fault lies on the React team, influencers and YouTubers that cater to the echo chamber. An entire generation of web developers started with React because code academies taught React. React is all they know, and they’ve been misled by sheer marketing that masquerades as best practices. The same could be said for other JS frameworks and libraries though.
I've always enjoyed using React as much as despised working with its toolchain. I think the churn is the #1 reason for both ugly DX on enterprise React and unpredictability of what to expect as a developer joining a React project. I hoped CRA and maybe Recoil (RIP) could have unified the ecosystem, instead they both got abandonded explicitly (CRA) or implicitly (Recoil). I don't know, Angular and Vue both are frameworks and give you a minimum viable set of libraries you need, while React doesn't and it should.
Why? COBOL developers now make more than React Developers. React has the same future as COBOL.
That’s pretty funny.
I may sound like a grumpy old man but engaging in ad hominem attacks to prove a point isn’t a good look. Nobody attacked your choice in library or you. Is all criticism with React met with this? We can’t even have a healthy discussion when people limit and dismiss others opinions out the gate.
Ever hear this excellent Nerd Rage rant at the top of my article? dev.to/iq9/how-to-escape-js-framew...
Couldn't agree more.
The costly part with React is that it's a very proprietary implementation. I've been coding for 35 years, and I had to take a 80-hour paid ($200) Udemy course before I could be productive on React. And even then, I wasn't sure which feature I was supposed to use to solve Problem X vs Y. It's unoppinionated, so there was a dozen different styles of doing things in those repos. Then another $200 course later and 120 hours, I was maybe 75% the spreed I normally am ES6 other. It can't be learned thru the usual method that 90% of devs use: experimentation! Experimentation only works if the technology has a conventional implementation. Or if it has a unique implementation, one so small, it can be learned in days anyway.
The following technologies at that same co, took me merely 3 days to be productive on, having never touched them before:
Another costly mistake I witnessed at my last 2 cos, spanning 5 years:
Quote from React docs:
Each has its appropriate use case. If they didn't, Class ones would have been purged from React, and its docs.
Then everyone realizes the mistake 6 mos later when devs are passing State around in creative ways. Then they throw Redux at the problem.
It's was entertaining watching these exact same thing transpire at 2 completely different cos.
I can relate to a lot of this. Had to learn how to bootstrap the React front end from scratch. Learned how to integrate it into antiquated C# ASP NET 5.0 code, which doesn't have direct support for it (oh the horror, copy to scripts folder, MSBuild / csproj magic and CDN fallback logic). Conflicts between CSS selectors and existing Bootstrap 4.0 classes and new Bootstrap 5.0 classes when rendered on existing pages on the website. Website includes more than a dash of JQuery on the webpages. It takes quite the effort to keep all that working and in sync.
I won't be able to upgrade the ASP NET 5.0 code to something newer for at least 2 years and it's going to be an absolute nightmare to re-code all those old pages and consolidate the separated React apps / JS into a cohesive unit. Code that delivers value stays around, even if it's not latest and great thing.
This line "OK, how would I do that without React?" is funny, because I distinctively remember saying that exact line about jQuery several years ago. I was activelly searching Google for how to target elements, add and remove listeners, and especially handling http requests, without relying on jQuery. Not long after, I came across React and Vue, and am working with them ever since.
I'm not yet feeling the same pull to abandon ship, though. jQuery already felt dead at that point, it was easy to write but terrible to maintain, and this made it unpleasant to work with it. With React I'm still having a lot of fun building applications that would take me years with jQuery. I'll stick around for a couple more years.
I'm working with React for some 3 years now and I never felt so productive, but I can relate to some of OP's struggles.