Here's my current opinion. Not comprehensive. Almost wonderment.
Which decade? The decade is mine. I've written a lot of React in that time. It has been a great tool.
Now, one of the latest features, React Server Components, has me thinking about that decade of React.
This is recent news because of Next 13. Way back in 18.0.0, released 29 Mar 2022, React Server Components landed with experimental support. They are still listed as experimental in the latest version, 18.2.0. But they're the hot new thing, for the first time usable in production with Next.js 13.
A Good Read
The recurred to my mind today when the talented Josh Comeau released his primer on React Server Components. As usual, it is beautifully done. Josh creates great learning material.
In giving my current take, I'll quote a few times from the Comeau article, which I think is representative of the React zeitgeist.
For the React Dev
Josh's article, as it says, is definitely written for a React dev:
This tutorial is written primarily for developers who are already using React
Maybe it's not just for the experienced React dev, but the dev who grew up doing React. React has been mainstream for some time. This audience would contain a lot of people.
Josh says that as a React dev, React Server Components were a surprise:
As someone who has been using React for many years, this code looked absolutely wild to me at first.
I might be misunderstanding him. Maybe he means something narrower, like "this looked wild because this is supposed to be React".
HTML Across the Wire
And what's so wild? The funny realization that HTML can be sent from the server in an async call? That data can be fetched with the markup? As he points, server rendering changes the user experience:
A server generates the initial HTML so that users don't have to stare at an empty white page while the JS bundles are downloaded and parsed.
And it's more performant:
Instead of requiring a second round-trip network request, why don't we do the database work during that initial request?
And simplifies things:
Server Components tend to be simpler and easier to reason about.
Back to 2012
React is great. But if the new hotness of React says to SSR your apps:
As a general rule, if a component can be a Server Component, it should be a Server Component.
, then why use React? Maybe because you like it, are skilled in it and provides a common API for once you need to use client components.
But, if that's it, then React has lost its hold on our imaginations, because tons of stuff can send HTML over the wire. And tons of stuff can render reactive interactions in the browser. And often simpler. And often more fun.
The React Mojo
The Mojo of React is its declarative pattern of
fn(data) => ui. I agree with Josh: the simplicity of that model is seen again in server components, and that's great. No imperative
React.useEffect there. But the simplicity is simultaneously obliterated now that React is synonymous with Next 13.4+: It has morphed from a ui lib into a full-stack framework.
Next 13 is pretty fun. But it's nothing special as an HTML renderer. Still, it can feel good as a recovery from JS-rendered UIs only. But client components are still likely: So you're still using
React.useEffect, passing refs, etc, and that's not all that fun.
At the least, I should say React has lost a bit of its hold on my imagination.
I guess Guillermo Rauch did say that:
React is such a good idea that we will spend the rest of the decade continuing to explore its implications and applications.
Maybe my decade with React is waning. What would I do instead? Not sure, but I want something that better captures my imagination, is more simple and more fun. Maybe: Run a Clojure backend, render HTML in templates and write raw JS for client interactions. Or web components with lit-html for more client interactions. Or maybe take another React job, hehe.