- Where it began
- What Astro means for the web
- Scalable complexity
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.
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.
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.”
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:
- User requests a page
- The full page loads in the browser
- User clicks a link to another page
- 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  . 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 , other metaframeworks could adopt it. For example, SolidStart has been exploring it since before RSCs dropped  and even the Astro team is exploring what client-side routing could look like in Astro .
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.
- Dan Abramov’s explanation of the difference between Islands Architecture and Server Components [Twitter]
- Dan Shappir’s explanation of the difference between Islands Architecture and Server Components [Twitter]
- Ryan Carniato: Into the Depths with Server Components and Functions [YouTube]
- Astro’s Roadmap: Client-side Routing [GitHub]