React Server Components: The future of getting started with the web

Contents

1. Where it began
2. What Astro means for the web
3. Scalable complexity
4. Summary

Where it began

If I were to start in web development today and I already knew some HTML, CSS and JavaScript, I’d be grateful to the person that convinces me to pick Astro over anything else.

I didn’t learn web development this way. I knew the very basics of HTML and CSS when I started programming in Java. And even though I fell in love with the web for how accessible it is, I didn’t want to be the person that wrote markup, changed the color of buttons or thought about what feature works in what browser. If I were to come onto the scene, I’d do it in a sophisticated way. I’d do it in Java.

I professionally built apps in Vaadin for a little over a year and as good as it was, it’s no longer for me and the things I’m building. What it did for me was it let me skip a whole lot of web fundamentals. I didn’t learn how forms worked. I didn’t know how to properly structure my markup to best keep things accessible. I didn’t even understand how to center a button component within a layout container because the docs assumed I understood enough of the web. I didn’t.

When I started taking web development seriously, I tried to go back to the fundamentals but there was a popular new kid on the block causing a racket. React. I tried avoiding it so I could learn some JavaScript and semantic HTML, but I kept hearing, “it’s just JavaScript”. Fine, I guess this is a two in one offer. Little did I realize, I was adding newer and newer abstractions over what I had, and what I had was absolutely nothing. React felt amazing. I felt like I was close to the fundamentals again but I wasn’t really. This isn’t a critique or an anti-React piece. I’m grateful for the doors it opened for me, and to be fair, it’s still paying the bills. If I already had a good foundation, I would’ve been in a better position to reason about the decisions I’m accepting and endorsing in my applications when using React.

What Astro means for the web

This is the reason why I think Astro is a great starting point. If I had come into web development, and been in a situation where I had to build and publish a website quickly, Astro would have me covered. Sure, I ended up doing the same thing with Next.js but I see that as another layer of abstraction over React. For me, this entire house of cards was build on feeble web fundamentals that were derived from the shortcomings of the abstractions Vaadin proposed. I needed fewer abstractions, not more. The exact combination of stacks might be unique, but I don’t think I’m alone in this experience. I think like me, a lot of us ventured into web development with varying levels of exposure to the web, and got given abstraction over abstraction to churn out features and entire applications with very little room to breathe or think.

If I had Astro, I could’ve had my component model abstraction. I could’ve learnt the benefits of scoped styling. I could’ve naturally sprinkled in the JavaScript exactly where I needed the interactivity. These are good and reasonable abstractions that empower you to build websites better than if you hand rolled them yourself. I strongly believe I would’ve spent more time learning about the web and all of the features it had to offer, while enjoying the benefits we’ve distilled from years of experimentation with tools like Angular, Gatsby, Next.js and Remix. As a novice, I would’ve had the best of both worlds with a package so simple that it would empower me to learn the web platform better.

This is why I love Astro. I see Astro as the baseline for anyone coming into web development. If Astro is the starting point, we don’t have to do our awkward explanation of the “MPA” acronym: “we only call them multi-page applications because of single-page applications, which were the new kids on the block. Multi-page applications are how websites have always worked.” That’s a lot of indirection. Now, it’s back to being simple: “Astro is how websites have always worked.”

Scalable complexity

Once we’re rolling with Astro, we can sprinkle in some more complexity, because let’s be honest, we can’t help ourselves. The model lends itself to incrementally adding this only where you need it. This won’t safeguard you from doing something completely unreasonable, but it does give you sufficiently simple building blocks to keep the magic to a minimum, and this ensures you can always reason about your code.

When you feel more comfortable at this level, the point now becomes less about Astro and more about the mental model of the Islands Architecture. Astro does the Islands Architecture well, but it isn’t unique to it. You can take this abstraction with you to other metaframewoks that support it and generally keep all of the benefits. We now know how the web works, serve different pages of your website, organize your code into components so you can reuse them, style these components without accidentally changing the style of another and add interactivity to different parts of the page. What more could you need?

That depends on the complexity of what you’re building. The model we have with something like Astro is very much suitable for a website, and you can push that quite far. By being an MPA, each page has its own markup, styles and interactive bits. If we were map out an end-to-end of this, we’d have the following:

1. User requests a page
2. Server responds with HTML, CSS and JavaScript
3. The full page loads in the browser
4. User clicks a link to another page
5. Server responds with the HTML, CSS and JavaScript for that page
6. The full page loads in the browser

Even if you reuse the same interactive component on both pages, they’ll have no way of knowing they are the same component. You’ll need this if you’re building something that’s more of an SPA. A workaround would be to store the state of the component from the first page in the client’s browser (using session or local storage) and then resume that state when the same component loads on the second page. This still doesn’t give you a proper SPA-like experience and for that we’ll need to persist those islands. How do we do this and just load the HTML around it from the server?

Enter Server Components.

React Server Components, or more generally, the Server Component architecture is what I think is the next iterative step in this journey. They encompass the Islands Architecture and extend it by persisting islands on page navigation [1] [2]. Notice, we’ve built up this complexity in stages just for what we’ve needed. At any point, we can drop all the way back down to output simple markup for any route within the same project. This model enables you to scale complexity up and all the way down when appropriate. There’s no magic in the mental model. There’s some implementation magic in how only the updated parts of the HTML from the server are patched in, but conceptually it’s dead simple. If you want markup, just use server components. If you want interactivity, then add client components for islands. And server components also have you covered when you want to persist those islands with SPA-like navigation.

In terms of tools, Next.js 13 currently supports RSCs but because Server Components are an architecture [3], other metaframeworks could adopt it. For example, SolidStart has been exploring it since before RSCs dropped [3] and even the Astro team is exploring what client-side routing could look like in Astro [4].

Summary

Coming into web development can be a daunting ordeal. If you focus on and build up your web fundamentals, you’ll be in a very good place to keep up with all the advances that happen in this space. Astro is a great piece of technology and it will instil in you a model of the web that is congruent with the web. The Islands Architecture lets you slowly scale up complexity only where you need it and it also makes understanding Server Components, the next step in this evolution, easier to understand and appreciate.

If you think of anything I have missed or just wanted to get in touch, you can reach me through a comment, via Twitter, via Mastodon or through LinkedIn.

References

1. Dan Abramov’s explanation of the difference between Islands Architecture and Server Components [Twitter]
2. Dan Shappir’s explanation of the difference between Islands Architecture and Server Components [Twitter]
3. Ryan Carniato: Into the Depths with Server Components and Functions [YouTube]
4. Astro’s Roadmap: Client-side Routing [GitHub]

Photo by Sigmund on Unsplash

Comments

[Hasan Ali]

Ryan Carnito: Islands & Server Components & Resumability, Oh My!