Island Architecture
Key points
- A new way to build web applications( as of October 2022).
- Tries to find a middle ground between SPAs and MPAs, as well as SSR and CSR.
- It generates static html with “islands” of javascript-based interactive components.
- Frame works like astro, qwik , marko, fresh etc uses island architecture. They claim that it is way faster than nextjs and similar frameworks, for certain use cases.
Summary
Island architecture promotes server-side rendering with static HTML with slots or placeholders for interactive regions. These placeholder regions are hydrated with client-side JavaScript. This way, we can have interactive web pages with minimal javascript that are fast to load.
Before javascript, web pages were always static. ie, They only had the HTML that the server send to the browser. No more HTML was generated by the client. Javascript changed all this by generating HTML on the go either on its own or in response to a user action. The computing power in the client has increased many fold in past couple of decades. This allowed Javascript to take an active role in the websites. Websites have now morphed in to full fledged javascript applications. Frameworks like React has made it so easy and popular to go the “web application” route. he old school approcah was to make websites with static HTML with some javascript springled in to it.
If you load a client-side rendered app build with a framework like React, with javascript disabled, you will most likely have a white screen. This is because the entire hydration process happens on the browser after the initial (mostly blank) HTML is loaded. Once the HTML is loaded, the framework code does the “hydration” or generates the usable HTML.
With server-side rendering, things change a bit. The server generates an HTML structure and sends it down to the client. So when the pages load, it already has a lot of content without running any javascript. Then the javascript runs. It attaches the event handlers(hydrates), and fills up the app with more useful things for the users to interact with. The initial load is pretty fast. Unlike pure client-side rendering, the user does not have to wait to start interacting with the page.
In both of the above cases, the frameworks are optimized for interactivity. But a vast majority of the web pages out there are not very interactive. They mostly have static content that the user consumes, with a small amount of interactivity. Imagine a new paper article with a comment section below the article. Or a marketing site with FB integration for likes and shares.
These types of pages will be forced to use heavy CSR or even SSR, when they actually need a tiny bit of interactivity. But for that tiny bit, they stand to lose on the google SEO rankings. Their initial load time is high and they don’t measure well on the metrics like lighthouse metrics.
There are a bunch of techniques that try to address this problem. Streaming server side rendering, Partial Rehydration, Progressive Rehydration and Trisomorphic Rehydration etc tries to reduce the amount of javascript sent down to the client and thus tries to reduce the bundle size, compute, load time and initial interaction time. They are often complicated to implement and not the default behavior of the frameworks.
Island architecture is trying to solve this problem. Some frameworks that support this architecture also offer some additional benefits similar to micro front-end architecture.
Jason Miller describes island architecture as,
“render HTML pages on the server, and inject placeholders or slots around highly dynamic regions. These placeholders/slots contain the server-rendered HTML output from their corresponding widget. They denote regions that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML”
On surface, this may look similar to progressive hydration (or PSSR - Progressive Server Side Rendering) , but it has some key differences. In PSSR, the hydration architecture is top-down. Page is in control of how hydration is scheduled and performed on individual components. But island architecture is more asynchronous. Each island is hydrated separately and thus the performance of one island will not affect the other.
Some frameworks like Astro has taken this to the next level. Where each of these isalnds can be a component written in a different library or frame work all together. For example one island can be react and the other can be vue.
This type of Architecture is most suitable for websites where interactivity is low, but not insignificant. For such use cases, islands offers better performance and better SEO.
There are a lot of new frameworks out there that support island architecture. Astro, Markojs, Fresh, Qwik are the few names that comes to my mind.
The easiest way to try this out is with Astro. Astro allows you to bring your on frame work, so you can write your interactive components in your favourite UI library (React, Vue, Angular … ).