Islands Architecture

What Is Islands Architecture?

Islands architecture delivers mostly static HTML and adds JavaScript only to isolated interactive components. Rather than making an entire page a browser application, it hydrates small areas, called islands, where interaction is needed.

How Islands Architecture Works

The server sends useful content first, while interactive areas load independently.

1. Render page content, including headings, text, and images, as server HTML.
2. Mark components needing browser behavior, such as menus, forms, or product selectors.
3. Send static HTML so the page is readable before JavaScript runs.
4. Load an island's JavaScript on page load, when idle, when visible, or after user action.
5. Hydrate the island by connecting HTML to event handlers and state.

A Practical Example: Product Page Islands

On an ecommerce product page, descriptions, specifications, and shipping policies can remain static HTML. An image gallery, size selector, add-to-cart control, and review filter can be islands. The size selector and add-to-cart control should usually share an island because both depend on the selected variant. Boundaries should follow shared state, not visual layout.

Benefits of Islands Architecture

This model makes interactivity deliberate.

• Smaller initial JavaScript payloads can improve first render and reduce browser work.
• Content remains HTML, supporting progressive enhancement and search crawling.
• Independent loading stops a minor widget from delaying the page.
• Clear boundaries separate content from interactive behavior in a web application architecture.

Practical Limits of Islands Architecture

Islands are not right for every interface.

• Separate islands can struggle to share state, such as a cart count updated in several places.
• Too many islands may duplicate dependencies and increase coordination work.
• Server and browser output must match during hydration to avoid errors or shifting UI.
• Controls still need accessible HTML and sensible behavior before JavaScript loads.

Islands Architecture vs SSR, SPAs, and React Server Components

These approaches can overlap. The best choice depends on how connected the interface is.

When to Use Islands Architecture

Choose islands when most of a page is informational and interaction is localized.

• Marketing, documentation, and editorial pages with forms or navigation controls.
• Ecommerce storefronts with product options, galleries, and cart actions.
• Dashboards with widgets that do not constantly share client state.
• Use a unified client state model when many controls must update one another in real time.

Designing Island Boundaries in Emergent

With Emergent, teams can identify server-rendered regions and interactive areas, then test loading behavior and state boundaries. This is useful when combining islands with headless architecture or planning a full-stack build through an AI web app builder. Build fast interactive web apps with Emergent.