I was listening to Wes and Scott on a recent episode of Syntax talking about RSCs (React Server Components). I wouldn’t say it was particularly glowing.

We use them here at CodePen, and will likely be more and more as we ship more with Next.js, which is part of our most modern stack that we are always moving toward. Me, I like Next.js. React makes good sense to me for use in a very interactive, long-session style application with oodles of state management. By virtue of being on the latest Next.js release, whatever we put in the app directory (“The App Router” as they call it) automatically uses RSCs when it can. I mostly like that. We do have to fight it sometimes, but those fights are generally about server-side rendering and making sure we are set up for that and doing things right to take advantage of it, which honestly we should be doing as much as possible anyway. I’ll also add some anecdotal data that we haven’t exactly seen huge drops in JavaScript bundle size when we move things that direction, which I was hoping would be a big benefit of that work.

But React is more than Next.js, right? Right?! Yes and no. I use React without Next.js sometimes, and we do at CodePen in plenty of places. Without Next.js, usage of RSCs is hard or not happening. Precious few other frameworks are using them, and some have thrown up their hands and refused. To be fair: Parcel has support in Beta and Waku also supports them.

A little hard to call them a big success in this state. But it’s also hard to call the concept of them a bad idea. It’s generally just a good idea to make the servers do more work than browsers, as well as send as little data across the network as possible. If the JavaScript in a React component can be run on the server, and we can make the server part kinda smart, let’s let it?

If you’ve got the time and inclination, Dam Abramov’s React for Two Computers is a massive post that is entirely a conceptual walkthrough abstracting the ideas of RSCs into an “Early World” and “Late World” to understand the why and where it all came from. He just recently followed it up with Impossible Components which gets more directly into using RSCs.

Welp — while we’re talking React lemme drop some related links I found interesting lately.

• React itself, aside from RSCs, isn’t sitting idle. They’ve shipped an experimental <ViewTransition> component which is nice to see as someone who has struggled forcing React to do this before. They’ve also shipped an RC (Release Candidate) for the React Compiler (also RC? awkward?). The compiler is interesting in that it doesn’t necessarily make your bundles smaller it makes them run faster.
• Fancy Components is a collection of “mainly React, TypeScript, Tailwind, Motion” components that are… fancy. I’ve seen a bit of pushback on the accessibility of some of them, but I’ve also poked through them and found what look like solid attempts at making them accessible, so YMMV.
• Sahaj Jain says The URL is a great place to store state in React.
• Joshua Wootonn details the construction of a Drag to Select interaction in React which is… pretty complicated.
• The blog Expression Statement (no byline) says HTML Form Validation is heavily underused. I just added a bit of special validation to a form in React this week and I tend to agree. Short story: GMail doesn’t render <img>s where the src has a space in it. 😭. I used pattern directly on the input, and we have our own error message system, otherwise I would have also used setCustomValidity.
• Thoughtbot: Superglue 1.0: React ❤️ Rails