Chris’ Corner: Server Side Reconnaissance

If you tend to follow React stuff, you might know that React has a new thing called “Server Components”. Mayank has an excellent blog post about them. It starts out with calling out the nice things about them, and then fairly calls out all sorts of not-so-good things about them. Me, I think it’s all weird as hell. Just the fact that React was “just a UI library” for so long now needs a Node.js server behind it to take full advantage is a heck of a leap. And it’s already gone so far that you have to say "use client" when you want a component not to be a server component? (But actually it means: “it’s both a server component and a client component”). Ooof.

I’d link you to the docs for Server Components, but there aren’t any. There is just an update blog post, and little mention in the Bleeding-edge React frameworks section:

These features are getting closer to being production-ready every day, and we’ve been in talks with other bundler and framework developers about integrating them.

So if you want to use them, you may only do so in Next.js. If you’d like to build them into your framework, you hold your breath until the React team reaches out to collaborate. Maybe that’s a little unfair, but I don’t see what you’d read to get started with it all, aside from trying to dig through Next.js code and see how they did it. We use Next.js here at CodePen so we’ll be able to take advantage, I just think it all feels strange.

Next.js is an ultra popular way to use React. So if you just happen to be using Next and staying up to date, you’re using Server Components. That might be advantageous to you. That’s frameworks at their best, really. You do very little, frameworks evolve and you take advantage of the magical things they do behind the scenes. But reality has shown that framework upgrades can be painful. Rarely are there major version upgrades that don’t require work due to incompatibilities. One casualty of this Server Side Components changeup is most of the CSS-in-React landscape.

Josh Comeau has a solid deep dive into this situation. It’s ultimately a pretty simple problem with no real solution at the moment for some of the libraries, like styled-components, arguable the biggest player:

The fundamental incompatibility is that styled-components are designed to run in-browser, whereas Server Components never touch the browser.

Internally, styled-components makes heavy use of the useContext hook. It’s meant to be tied into the React lifecycle, but there is no React lifecycle for Server Components. And so, if we want to use styled-components in this new “React Server Components” world, every React component that renders even a single styled-component needs to become a Client Component.

It’s not the end of the world because, well, if you use them your stuff will need to be client-side only like it already is.

Just to prove what a smart, forward-thinking, attractive, good-smelling person I am, I’ve long been a fan of CSS Modules, and they have no such problem, as they don’t promise to do dynamic things that only JavaScript can do, it’s largely just a scoping API. Likewise, any other of these CSS-in-React libraries that promise “Zero-Runtime” are in good shape. That was really the way to go all along, if you ask me. Styling choices shipping as static CSS is with the grain of the web in a good way.

React is evolving in other similarly massive ways as well. Adrienne Ross has a pretty great rundown in Get your codebase ready for React 19. The massive thing is that it’s going to be a compiled framework (!!!!?!). So totally gone is the “it’s just a UI library” situation that was never really true but now is extremely very not true. While it’s a massive change for React itself, I imagine it won’t be a massive change for developers. People developing with React are almost certainly using a build process anyway and the React compiler will become a part of that. If you’re on the Next bandwagon, surely it will smurf its way into that pipeline. Maybe it will only be available in Next?! I’d say that sounds wild, but since that’s literally what is going on with Server Components, it almost seems likely.

Svelte feels like the first major framework of this generation to require a compiler, and by and large I think people applaud it. It makes client side bundles smaller and it makes authoring work easier. Easier, because you aren’t responsible for figuring out specific details when the framework needs help being performant. The use of useMemo and useCallback in React are performance-specific hooks that if you aren’t using or using incorrectly are hurting your application. That sucks. The fact that you don’t have to think about them anymore with a compiler is a welcome upgrade.

What I’d like to see, and I know there are many who agree here, are client-size bundles sizes actually coming down. In that first article I linked up, Mayank noted that despite Server Components existing now, JavaScript bundles headed to the client are increasing. Again, that sucks. I’m sure the story is very different in fully fleshed out applications that can take big advantage of Server Components than it is for a Hello, World scaffold, but still, we want them coming down across the board.

React is such a monster player on the web right now, I think of it in the Too Big to Fail category. Whatever whacky choices they make, developers will just fall in line. Companies write checks for developers that know React, and the job market sucks right now, so the pressure is even higher to know React. Perhaps even force yourself to love it.

Technologies do tend to come and go. I’m sure we all have our own examples of web tech that was once big and is now all but gone, or at least gone from good graces. But when tech gets big enough, it tends to not go. WordPress is huge, and it’s been huge every second of my entire web dev career. To me it echos social media in a way. In the middle days of Facebook, it’s demise was often predicted. Friendster died, after all. MySpace bit the dust. Google+ came and went. People are fickle. So too will Facebook die and be replaced by the new and shiny. But it didn’t, and it’s demise is no longer predicted. It’s too big to fail. So too is React.

CategoriesUncategorized