Building the Web in Islands, Not Mountains

Not every site needs to be a full-blown app. In fact, most don’t. What they need is to be fast, focused, and respectful of the user’s device.

Put another way: if your ‘About Us’ page needs 300kB of JavaScript to render a sentence about your mission, it may be time to reconsider.

---

We’ve leaned heavily into building everything as if it were an application: routing, state, hydration, and all. That approach works brilliantly for complex, interactive experiences. But for many sites, it leads to overengineered pages, unnecessary JavaScript, and slower interactions.

There’s a better pattern, and it’s gaining momentum again. It’s called islands architecture, and it offers a way to ship less, do more, and give users speed where it counts.

The Problem With “One Big App”

Single-page apps (SPAs) brought a wave of innovation to the frontend. They gave us smooth routing, shared state, and dynamic interactivity. For many use cases, they remain the right choice.

But when every page becomes part of one large application, even simple, mostly static ones, we start to pay a price. That price often includes larger bundles, delayed interactivity, and more work for the browser than is truly needed.

If your marketing page or blog post loads the same hydration logic and route configuration as your account dashboard, something is off. It creates work that doesn’t need to happen, especially on mobile.

What Is Islands Architecture?

Islands architecture takes a more selective approach. It renders the majority of the page server-side, using static HTML whenever possible, and hydrates only the components that need to be interactive.

Picture a page as a landmass. Most of it — layout, content, structure — is pre-rendered and delivered instantly. Then come the islands: self-contained interactive parts like a search box, a shopping cart, or a comment form. These hydrate independently and only when needed.

Instead of treating every page like a fully hydrated application, you focus interactivity where it adds the most value.

This Isn’t a New Idea

Before SPAs and JavaScript frameworks, developers often rendered pages server-side and used scripts sparingly to enhance behavior. You’d write HTML, sprinkle in jQuery plugins, and call it a day.

In hindsight, this was a kind of early islands model. The challenge was maintainability. Everything felt stitched together.

Today’s tools bring back the same mindset, but with component-based discipline and modern developer ergonomics.

How Islands Work in Practice

Frameworks like Astro are built with islands in mind. You can specify how and when a component should hydrate:

<InteractiveRating client:idle />

This tells Astro to render the component on the server and hydrate it only once the page is idle. Other directives include client:load, client:visible, and client:media, letting you match hydration to user context.

Other frameworks take similar or adjacent approaches:

• Qwik uses resumability, which avoids hydration entirely by serializing state for instant interactivity.
• Enhance.dev leans into web standards and progressive enhancement.
• Fresh (Deno) supports islands as a core rendering model.
• Even Next.js, with React Server Components and the app/ directory, is giving developers more fine-grained control over what runs where.

These are not opposing models. They are part of a broader shift toward delivering more HTML and less JavaScript when appropriate.

Why It’s Fast

• Less JavaScript up front means quicker interactivity.
• Fewer layout shifts make the experience more stable.
• Lower memory and CPU usage helps users on mid-range or older devices.
• Core Web Vitals like LCP, INP, and CLS often improve naturally.

And most importantly, it feels better. The page is usable immediately. You don’t wait for hydration to finish or for a loading spinner to disappear.

When to Use It

Islands architecture shines when:

• Your content is mostly static, with pockets of interactivity.
• You care about first load performance.
• Your audience includes mobile users or bandwidth-constrained regions.

It’s a great fit for blogs, marketing pages, documentation sites, and e-commerce product pages. Anywhere that’s mostly static but benefits from pockets of interactivity.

For complex apps with deep state and interactive workflows, a hybrid model may make more sense.

But even there, treating your UI as a set of islands can still lead to smarter hydration, clearer boundaries, and better performance.

It’s Future-Ready Too

The trend is clear. Edge rendering, streaming, and component-level monitoring are all rising. Islands work well in this environment.

They support:

• HTML streaming for faster time to first byte.
• Incremental rendering and delivery.
• Real user monitoring at the component level.
• Smarter delivery based on user context such as device, viewport, and connection speed.

If your stack supports server rendering and hydration control, you are already most of the way there.

Build Islands, Not Mountains

Modern frameworks brought us power, flexibility, and developer joy. But they also nudged us toward treating every site like a full application.

Islands architecture brings balance. It keeps the parts of modern development that work, such as components, server-side rendering, and interactivity, and refocuses them around speed, simplicity, and user needs.

You don’t need to build a mountain for every page.
Islands get users where they need to go.
Without the altitude sickness.

---