Ruben CasasEarlier this year I had an interesting conversation with a CTO of a price comparison website (e-commerce) and he mentioned that they are moving away from React.
“Wait, what?”… was my Reaction (pun 👊 intended)… please tell me more!
“Yeah, it is not working for us, we are moving away for performance reasons, e-commerce is a really competitive market and we need to ensure our site is 100% performant to beat the competition”
Ok, fair enough, I thought…
You must have found a considerably better framework right? so where are you moving to?
Vue? Svelte? SolidJS? Qwick? Astro? (cough, heavens forbid) PHP?
“No, we are just keeping React for server-side rendering for now and using Vanilla JavaScript in the frontend”
That was not the answer I was expecting and unfortunately I didn't have time to enquire more about their decision, but it got me thinking.
Is this going to become more common now? are people moving away from React the same way we saw the mass migration out of AngularJS back in 2014/2015?
React is Getting Old
React will be 10 years old on the 29th of May 2023 (finally recruiters are able to ask for 10 years of experience, without being a laughing stock)
This means that applications are also starting to get old, and when applications start to get old, you start finding issues, loads of them.
- A hard-to-maintain codebase
- Legacy patterns
- Old and new code mixed
- Multiple or old state management libraries
- CSS-in-JS
Something very important to note here before we continue is that none of the problems listed above has anything to do with React itself 🤔
So is React the problem?
I have observed something really interesting and is that we as developers like to find culprits, but when the culprits are not very obvious, for example, when the issues are related to processes, company culture or just bad practices, we turn the blind eye on those issues that are affecting our applications the most and convince ourselves that the problem must be the technology because it is something we have somewhat control over.
It is easier for engineers to suggest and convince leaders in organisations that if we change the technology we will somehow magically solve all the other problems. So when a new technology or framework promises to fix some issues that we might have, (but are not the main issue), we start focusing on them and start suffering from “tunnel vision”.
For example, in terms of performance which is one of the main reasons, people start looking at alternatives to React, in most cases, the framework is only responsible for a small fraction of a bad user experience. Most of the time they are caused by bad practices, incorrect abstractions and bad ideas terribly implemented.
When we compare performance benchmarks between different frameworks we usually create an application that is not close anywhere near to the real world, and I am not talking about the type of application. Some demos are better than others and you can create a really comprehensive UI that is not a “Todo App”, but even with that, it has been created in a “lab environment” following the best practices, with no constraints, tech debt or cutting corners to make it to the next release.
Applications in the real world are not built like that, they are messy, often rushed, and developed by multiple people, so for us to fight for the last millisecond is pointless when our network latency, backend APIs and bundle size (cough cough SPAs) are the main culprits.
It is all a matter of what percentages of your problems are caused by React itself and what is important for your application. In the case of that CTO, they did as much as they could to fix their issues, and then came to the conclusion that React was to blame for the performance so they had to change it, but it is one of those rare cases, especially in e-commerce where profit margins are so slim that every millisecond counts.
One thing I can say about React is it exacerbated other problems by being “unopinionated” and not providing some guidelines. It didn’t provide a way for developers to fall into the “pit of success”. Multiple competing patterns emerged that in hindsight have been really bad for our React applications… but oh well, we didn’t know what we didn’t know back in 2015.
To Migrate or Not to Migrate
A lot of companies are late to the party and they are still thinking about migrating to React, not away from it. It is easy to get into our little bubble and not realise that most companies don’t move near as fast as in our industry and they are still a lot of them (especially banks) that have not started or are still in the process of migrating.
For those who have been using React for a while, I sense that there is little appetite for another “AngularJS” style migration in the near future. (if you are one of those like me who led an AngularJS migration at our companies, congratulations! we completed our rite of passage 🍾)
It was a big investment, millions of dollars, countless of engineering hours, hundreds of billions of… you get the idea… it was expensive!
Good luck trying to convince decision-makers to do that style of migration again.
The only thing a big bang rewrite guarantees, is a big bang
– Martin Folwer
What I am hearing is that companies are not thinking about doing a big bang migration again, but they are updating their React codebases, using better patterns that have emerged recently and removing a lot of the tech debt that is causing most of the issues of applications that are getting old.
Stockholm Syndrome
React is not perfect, there are really good Javascript frameworks libraries out there that can offer a lot of features that are considered better than the ones that React provides. So why is React still so popular?
Is this a case of Stockholm syndrome?
Stockholm syndrome is a coping mechanism to a captive or abusive situation. People develop positive feelings toward their captors or abusers over time
– Wikipedia
I think so, and it is not just React, the same can be said about JavaScript as well (and React is just JavaScript right?)
It is not that bad! we can get the job done, it is flexible, it is popular and most of us owe our careers to them.
Is React going to be here in the Next 5 years?
Short and easy answer… yes! we will see people adopting new frameworks for new projects but I expect React to remain as the market leader JavaScript Framework library.
What about in 10 years?
I firmly believe that React is not going to be replaced by one of the slightly better alternatives, I believe that there will be a complete transformation in the near future.
What that is going to look like? no idea but something interesting is that we are still using user interfaces and peripherals from the 70s, we still write code in a very similar way just with slightly better patterns and tools. Things like resumability, islands architecture, progressive enhancement and all those fancy new patterns are just a slightly better more efficient way to achieve the same goal with a better architecture but there hasn’t been a major shift in how we write or produce software or frontend user interfaces.
This theoretical new tool that will replace React is going to change the game completely, it will change the way we interact with computers and software. It could be in the form of AI, conversational UI, Server Driven UI with infinite personalisation powered by ML, holograms ala Star Wars or “Insert your favourite SciFi film here”.
One thing is sure, even with the recent updates to React and even if you don’t agree with the direction the team are taking, React is not going anywhere. You don’t need to replace React today, what you need are better processes, best practices, decoupled systems and improved organisation structures and pay your tech debt.
If you want to get into the “milliseconds war”, ensure that you fix your other more important problems first and that millisecond is worth making you switch to another Javascript framework.
This article has been inspired and is the result of really great conversations with Kent C. Dodds, Jay Phelps, Ben Lesh, Niall Maher, Jhey Thompkins and all those amazing attendees of the “Conference that shall not be named” All the credit to them.
