(I wrote the following as a Twitter/Mastodon thread. Reposted here for posterity. Lightly edited and expanded.)
“The Perils of Rehydration: Understanding how Gatsby/Next manage server-side rendering and rehydration”
I have mixed feelings about posts like these. These frameworks are the wrong tool for this specific job.
React, Gatsby, and Next all have a time and place. But most of the time, if you aren’t building a highly dynamic productivity app, they are a bad fit. There’s a reason why most of the actual web is running Wordpress, Rails, or Laravel. Amazon’s ecommerce site is almost entirely server-rendered.
(It would be economically catastrophic for Amazon to switch its ecommerce site to React with Gatsby/Next-style rendering and hydration. Even if they could magically switch the entire site for free.)
Server-side-rendering with progressive enhancement is, most of the time, just a better solution for your web development problems. Cheaper to develop. Cheaper to run. Better performance both on desktop and mobile. Much better performance if you need to personalise the response. Cases that require React’s dynamism and architecture and can tolerate its higher bandwidth and performance costs compared to alternate frameworks are genuinely rare. They are edge cases. (Microsoft’s Office suite is a great example of when React, specifically React Native, is absolutely the best tool for the job. These situations definitely exist; just aren’t common.)
But alternatives to React don’t get a look in. Everything is React, all the time, everywhere. You don‘t even get to the point where you compare costs or performance for the problem in question.
It would be as if you were only allowed to drive SUVs.
It feels like the web dev community has become a React hegemony even though it’s rarely the best solution and is only used on a minority of sites. The web in general is built using tools the React/web dev community overtly labels as “legacy“.
The way the web dev community behaves these days is as if the online community of native app developers had decided that Unity was the only way to develop native apps, no matter if it’s a word processor or spreadsheet. Meanwhile, actual app dev would truck along regardless because most of it is a matter of maintaining and evolving pre-existing apps.
What’s worrying is how this affects recruitment. Most websites and services out there aren’t built with React. They’re overwhelmingly server-rendered. But you’d be hard-pressed to find devs who have any sort of training outside of React, even in basic HTML or DOM APIs.
I’ve been the tech/coding person sitting in on a bunch of interviews over the past few years and it has been rare to encounter an applicant with any sort of experience outside of React.
Which means most orgs either use React in circumstances that increase costs and lower performance, effectively letting web dev groupthink overrule development strategy or they invest in training.
Modern companies generally don’t have a clue how to train (no matter what the position) but they do know how to spend money, so you can guess which they tend to choose.
I’ve enjoyed using React the few times I’ve chosen to use it. I really have. It’s a great tool for a number of problems. But the web platform has evolved. Standard APIs are more capable. Alternate frameworks are available that better fit common use cases. React isn’t the best tool for every job.
So, I have mixed feelings about posts like these.