The future of SSR is RSC?

This edition's topics:

• RSC's future dominance
• Wait ... what exactly is JS Everywhere?
• Some useful (and spicy) React critiques
• 🚀 Changelog review
  • SvelteKit 2.0
  • Vue 3.4
  • Nuxt 3.9
  • SolidStart 0.4.0 - Beta 2
• 🧑‍💻 Tool links
• 🗞️ Blogosphere

RSC's future dominance

There’s a lot of ways to build a single-page app (SPA), but when early-stage startup CTOs have asked me in the past which technology to build on top of, I’ve really only given one standard answer: React.

To be clear, I’m not particularly fond of React as a technology, but its grip on the zeitgeist feels ironclad. The reality simply is that it has become the de facto default option for front-end development. If you are about to join a bootcamp to get into software engineering, they’re going to teach you React. If you’re looking to hire, there are going to be far more React devs out there than Svelte.

It is what it is. Your 20+ useEffect statements that are only understood by one dev on your team aren’t going anywhere.

I’ve known this for a while now when it comes to SPAs, but are we already on the path for that state in the realm of server-side rendering (SSR)?

A great post from RedwoodJS community lead Barret Burnworth crossed my path last month titled The Ubiquity of React Server Components. It outlines where he sees RSC headed in the near future.

The more detailed version of the post on Spoke gets into the strategic mapping philosophy that drives his analysis, but this summary of RSC’s current state is worth highlighting (emphasis my own).

RSC feels like it is still in the 'Custom' stage, even with NextJS having an implementation. Even after RW's v1 implementation, and even after Remix's comes online, RSC will still be in the early stages of 'Product.' This stage is where the product becomes 'off-the-shelf' and standard practices become established.

With RedwoodJS making it clear that its next big release will be centered around RSC and Remix recently adding RSC to their roadmap, that sounds like we’re not far away from this Product stage. Two more major React frameworks moves it beyond a NextJS experiment, which is how I had it logged in my mind in the days after Vercel brought out their "stable" release of the pattern.

There are obviously other ways to accomplish SSR. Nuxt uses Vue, SvelteKit uses Svelte, and Astro allows damn near every component library. Even SolidStart, the beta full-stack framework around SolidJS, offers SSR.

But the NextJS getServerSideProps strategy is where I peg the SSR concept capturing the zeitgeist in a unique and noticeable way. Fast forward a couple years and now NextJS’ momentum has been fully transferred to RSC, which is really quite remarkable when you realize NextJS 13 was released only 14 months ago. Perhaps that’s the power of having Vercel/Meta money backing your project.

If you like RSC, then this isn’t really a problem and probably isn’t even interesting. This likely only matters for general devs if they aren’t fans of React. Getting your team to shift to Vue/Svelte will be even harder once the industry momentum is largely moving the other way.

I'd personally prefer is something else drove this shift, but having one giant can be better than a dozen small players. Sometimes it's nice to be able to answer someone with a begrudging "Just use React" response.

Wait ... what exactly is JS Everywhere?

Here’s my personal bias: I think SSR is the new default.

SPAs were the default approach to building web apps for a solid decade (thanks largely to the influence of React). Over the past five years or so, I’ve seen the industry start to reckon with the side effects of that default: loading icons everywhere, having to solve routing when the HTTP spec already solves it, large JS bundle sizes and the security concerns that come along with them, etc etc.

After a brief flirtation with Jamstack, I think the industry is on the path toward cementing SSR as our new default approach. The full-stack frameworks are plentiful, bringing us into another round of JS framework debates, and so is the money with the amount of venture capital in the space to go along with the big players (Vercel, Meta, and Netlify).

So what follows from that? If you're doing SSR, your backend is going to be in JavaScript. My hot take is that languages like Python and Java are going to slide over into speciality use cases, i.e. heavyweight things that don't affect the UI but need some of that classical Computer Science 101 beef to get things done, like big data (Python) or something that requires strict object-orientated design (Java).

But the bulk of the "standard" tech stack just seems like it will be JavaScript. If you're using a full-stack framework that's using JS, why add in another language/framework unless you really really have to? Why hire for a whole different skillset?

It doesn’t come without tradeoffs. Now you have to deal with a server. Now you have less interactivity. And yea, it does feel like we’re re-building the PHP servers of before.

But tech executives are going to love not having to hire engineers with a different skillset. Like most things, this won't come down to a battle of technical specs. It'll be a shift accidentally triggered by middle managers once they realize that 1 programming language is less than 2.

And that language, for better or for worse, will be JavaScript.

So I foresee a JS-everywhere industry coming in the next decade. Some would argue we're already there but the most recent developer survey from Stack Overflow pegged Python as a close #2 to JS (and even a #1 depending on the demographic).

Some would argue the industry has been moving to this JS-everywhere mode for a long while. But there used to be a fairly hard line where folks defaulted to something else once they crossed from the front to the back end. This recent surge in full-stack JS frameworks feels different. There is no line to cross now. I'm predicting a world where something like Python becomes a niche language like Rust while the bulk of us normies "just use JS."

And some would argue "Dude, you've been making this argument during happy hours for at least a year now." True.

Well, now I'm channeling that energy someplace more productive. This newsletter.

Like most predictions, this one will likely turn out to be wrong. But I view all of this change as fun. A better word might be "entertaining." These framework A vs framework B are enjoyable if you don’t view them as life and death debates. We’re all software nerds trying to out-nerd each other.

So since I'm following all these trends anyway, I wanted something to put pressure on me to dive deeper into the weeds of these technologies and their macro effects.

So welcome to JS Everywhere, where everything is JavaScript and the stack traces are unreadable. This will be my spot to keep track of how wrong this prediction is and to work through ideas in a way you just can't during your 9-to-5.

Here’s some questions I want to work through that will likely make it into these biweekly newsletters:

• Does SSR change the whole Vue vs Svelete vs React debate? Does it even matter anymore?
• I’ve been hands on with NextJS, Remix, Astro, and RedwoodJS, but I definitely want to play with Nuxt and SvelteKit to complete the round up.
• Wait, should we just go all the way back to PHP? They say Laravel is pretty dope nowadays.
• Does SSR change the argument for Web Components one way or the other?
• Should we be concerned with the amount of money coming in from well-financed platforms?
• Angular doesn't seem like the past-its-prime framework it used to be. Should the industry be taking notice? Or can we all keep making fun of them like we've been doing for the last five years?

That's just a small brain dump for now. Come along for the ride to see just how wrong my predication will be.

Some useful (and spicy) React critiques

If RSC is the future, I’ve found myself clicking every RSC blog post I see. It's the nerdiest form of click bait ever devised, but it sure worked on me.

Since my early experience using NextJS 13 last year left me confused around the RSC concept - it felt like everything was in a beta state - I'm all ears (and clicks) right now around the realities of RSC.

Conveniently, the blogosphere was recently all atwitter on the subject thanks to Mayank's React Server Components: the Good, the Bad, and the Ugly piece. The post made nearly every newsletter I subscribe to with some commentary added here and there, most notably a hour-long read through from Lee Robinson, Vercel's VP of Product.

Mayank's spicy tone in the article is tailor made for Internet reaction. I stay off social media, but I can only assume that the online dev community (which takes place far too much on the platform formerly known as Twitter for my liking) was filled with potshots from both sides of the React debate. But I did find the article well thought out and find myself drawn to its conclusion.

These aren’t “unsolved” problems; these are invented problems that are a direct consequence of the way React is designed. In a world full of modern frameworks (Svelte, Solid, Preact, Qwik, Vue, Marko) that do not have most of these issues, React is effectively technical debt.

I’d argue that adding server capabilities to React is much less important than fixing its many existing issues.

Bonus spicy points for the "technical debt" jab. *chef's kiss*. But the more important piece is that this blurb followed a 8-point list of the "unsolved problems" with React, half of which are some real "maybe I shouldn't use this" hurdles for me personally.

There's still an argument that React's benefits are worth it, particularly since the industry's momentum has been behind React for a long time now. You can still can call me a begrudging React dev.

A more useful post (and less spicy) I had to bookmark was Josh W. Comeau’s September writeup Making Sense of React Server Components. It's a great run down of how to think about RSC. I found it more useful than the React docs themselves on the subject.

The overview of client boundaries (which remind me of island architecture popularized by Astro) is important to grok. These are the type of tradeoffs that are usually left out of the marketing materials for technologies like this. You get these cool new server features, but now you need to factor in client boundaries as you organize your components. Still might be worth the tradeoff, but I'd like to now about it beforehand.

And then there is this all-time post that is continuously being updated: A Historical Reference of React Criticism from 11ty's Zach Leatherman.

I caught wind of this reference back when The Market for Lemons from Microsoft's Alex Russell was making the newsletter rounds. (You pay enough attention to this for long enough and you'll see that a spicy React critique piece becomes a hot topic every 6 months or so.) I think that was the first piece that transitioned my own personal SPA fatigue into React fatigue.

The breadth of this reference piece really drives home that React has been a controversial technology from the beginning. I still remember trying to grok why React does so many re-renders without you even asking. (Spoiler: I still don't know if I've fully answered that.)

🚀 Changelog review

SvelteKit 2.0

On the surface, the term "shallow routing" doesn't seem that interesting. But here's the Svelte team describing the feature in their announcement.

Way back in the mists of time — May, to be precise — we teased a new feature that allows you to associate state with a history entry without causing navigation. It's very useful for creating modals that you can dismiss by swiping back, or pop-up views of routes you don't want to do a full navigation to.

That actually sounds pretty slick.

The other noteworthy thing here is that this upgrade will get you ready for the Svelte 5.0 release coming later in the year.

Vue 3.4

Let's get the obvious out the way first: "🏀 Slam Dunk" is an awesome code name for a release. I unironically vote for more emoji-based code names.

The more tangible impact I see here is the update to the reactivity system, which eliminates re-renders on redundant computed values for free. If a value goes from true to true after computation, the component isn't re-rendered. I'm impressed that this appears to work for arrays as well, which is always a thorn for reactivity logic.

With the rise of front-end frameworks around these component libraries, I've started valuing the component libraries for the reactivity, so it's nice to see Vue continuously improving on their approach.

I'm also loving the new v-bind shorthand (i.e. <img :id :src :alt>).

Nuxt 3.9

Interactive server components? That's a thing? How?

On the surface this sounds like an oxymoron, but there it is in the release notes. You can specify a component within your server component with nuxt-client and then it's interactive.

Honestly, it kind of hurts my brain to imagine so I'm definitly going to have to play with this to fully understand it. This interview with Nuxt core team lead Daniel Roe, apparently recorded before 3.9, alludes to the feature but doesn't go into details.

I'm super interested in this interactive feature, but there's also a new callOnce hook that's perfectly named.

SolidStart 0.4.0 - Beta 2

This beta project is still getting its feet underneath itself. This beta 2 release seems to involve a lot of refactoring to better set the project up to getting to a v1 release, including moving toward Nitro, the same engine that powers Nuxt, and a more extendable routing API.

Most interesting is the adoption of the "use server"; convention from the React world. Considering that Solid already adopted the JSX trend, it's notable how React conventions are leaking to other ecosystems. This likely isn't a big deal (nor is it positive or negative) but more of an example of the influence of React.

🧑‍💻 Tool links

• Once you start dealing with SSR, hydration errors will quickly become a part of your life whether you like it or not. I've always felt that framework authors will need to think about the DX of debugging these type of errors. Well, the folks at builder.io just offered a great first cut to the zeitgeist about what that DX should look like with their HydrationOverlay component. And it seems like a great implementation.
  • Note: I can't seem to find a visual for the improved hydration error handling in Vue 3.4. I'm curious if they take a similar approach and we're all coalescing around a strategy here. Something to compare once I get my hands into the new Vue release.
• David East of Analog.js - a full-stack framework around Angular - offers a quick example of the framework's result of bringing in single-file components to the Angular ecosystem. There's so much cool stuff going on in that ecosystem. It's easy to forget about how far it has come in recent years with the industry's React-or-bust mentality.
• It's not really a tool - more of a collection of tools - but Flavio Copes' AHA Stack ideas seems tailor made for a SSR, as-little-as-JS-as-possible glutton like myself.
• I'm really annoyed that I'm just now realizing useHooks exists. I'm pretty sure I've written half of these hooks already in my day-to-day. 🤦

🗞️ Blogosphere

• 🧑‍⚖️ This Should You Use Next.js? Let Ace Attorney Tell! video has to be the most niche thing that I’ve ever actually understood.
• 😢 This AI-generated article popped my Google Alert a while back. So this is what they mean when they say AI will kill publishing. How long do you think it took me to realize it was a fake?
• 🤦 11ty’s Zach Leatherman does a great job analyzing some questionable math from this years Netlify survey. You mean a survey from a for-profit company can’t be trusted at face value?
• 🕰️ Dear browser gods, please get this Temporal API implemented as soon as you can. I know you’ve likely got a gazillion security features on your plate, but have you actually used Date lately? No? Exactly! Sincerely, every dev.
• 🙃 Yet another React post with a little bit of spice added to it, this one from Josh Collinsworth. To be fair, this one comes off much more pro-HTML than anti-React by the end, which is refreshing.
• 🌊 Svelte Vietnam offers a clever and bold way to work around the hydration blip that comes with SSR - a splash screen. I predict devs and designers are likely going to have to come up with various UX approaches to the hydration blip and, as Svelte Vietnam points out, it'll likely have to be done in vanilla HTML and CSS 😱. Ideally frameworks will provide tools to help though.