Navigating Islands of Interactivity

So, what is an island? Interactive JavaScript component that is hydrated separately from the rest of your page. You send static HTML from your server to the client and then progressively load the JavaScript you need for the interactive elements of your page. It looks a little something like this.

So you have your static page here. Your header may have interactive components, maybe a search bar, maybe a shopping widget. Your image carousel will have interactive JavaScript components, but the rest of the page is just completely static HTML and doesn't need to be loaded.

So where does island architecture come from? Well, island architecture was originally coined by Jason Miller, the creator of Preact, back in 2021. However, the concept goes back further and he has credited KT Sillnull-Miller with coining component islands, which is this similar idea where you render HTML on the server, then hydrate those interactive components on the page rather than hydrating the entire page with JavaScript. Islands have been adopted by a few different frameworks, Astro, prior versions of Marko, Fresh, and Quig. There have also been demos in Eleventy and in Preact.

So how do you use islands? Well, I'm going to show you how to use them specifically in Astro and Fresh, two frameworks that have integrated islands very heavily. But there are fantastic examples out there on implementing them individually in your own framework. In Fresh, it's very simple. All you need to do is place your component in an islands folder and import that island wherever you need to use it. In Astro, it's a little more complicated. You can use client directives on those framework components to load them in different ways. So in this example, we are importing payment model, which is a React component in our Astro file. We're using it down here and we add the client load component. The client load component will render the HTML on the server, ship it to the client, and then hydrate the component on the page. This is normally the way in which islands work. There are a few others. So in Astro, we have several different client directives. Client load is the usual one that you'll be using where you render the element immediately on page load. Client idle will wait until the page has loaded. And then when the page is idle, will load your component. Client visible will hydrate the page when it enters the viewport. A form for the component, which has an interactive element, any visitor that does not scroll down to that component will not receive that JavaScript. Client media, so if you have an element that maybe only is visible on mobile, maybe a certain type of navigation, then you can avoid loading it on larger screens. Client only is a little special. It only hydrates on the client.

So rather than pre-rendering the HTML on the server, it will only send the JavaScript to the client. This can cause some issues with layout shift and things like that. But it can also be very helpful if you don't want to render any of those components on the page. And you can create your own directives. A great one as an example was rainy in New York, where your client component would only load if it was raining in New York. But you can define a small component, which will allow you to define whatever behavior you want. That could be whether you're waiting for a button press or you are calling some API to find out if some event is happening.

So what are the benefits of islands? Well, smaller pages. You don't need to ship the JavaScript where you don't need it, and you don't need to ship as much of it. And with that, you get faster LCP. You're not waiting for your entire component, your entire page to load JavaScript and run that JavaScript for the entire page. JavaScript is the heaviest form of content that you can ship to a page. So the less of it, the better. It also loads components in parallel. If you have three, four different islands on a page, these will load in parallel. You don't have to wait for one to finish before you load the next. And finally it gives you fine grain control over the JavaScript that you ship to your users.

So when should you use islands? Well, there's a few different places. In eCommerce, you can use it for product models, cards, recommendation widgets, any kind of interactive element on the page. But given that most of your page is going to be static, doesn't have any kind of API, it's not going to be a good idea to use islands. Media sites, you can use this to load video players, comments, modals, forms, anything that you might need. Docs and blogs, code playgrounds, interactive charts, any kind of small components that require some JavaScript but don't mean you want to render the entire page in JavaScript. Even if you do, you can use this in dashboards for small amounts of hydration with charts and filters, or even to load your entire app. But how do we share a state between all of these different islands? Islands, especially in Astro, can be from different frameworks and have no built-in way of sharing state. One of my favorite ways to do that is using a library called Nanostores. Nanostores is a tiny, tiny state manager which allows you to share state across pretty much anything. It has zero dependencies and has integrations for preact, react, Vue, Svelte, Angular. You can use it in a normal script tag. Quick example of Nanostores, we import our atom here.

Quick example of Nanostores, we import our atom here. We create a small, small atom which contains a number, and this is just the number of items in a cart. You can create more complex objects, but keeping it simple here for now, we have two separate items here. These are just basic React components. All we need to do is import specifically from Nanostores react when we want to use that store, and then we can add and we can modify that store by getting a setting state as you would with any kind of store in other languages, solid and such, but this one can be then imported anywhere across your app.

So, what are the key takeaways of islands? Well, the web doesn't have to be an SPA. You don't have to ship JavaScript for every single page, even if you think it is one of those more complex scenarios. Think static first. Think simple. Add that complexity, add that interactivity, add that JavaScript as you need it. Keep things as simple as possible, and add as you go. Use client directives for more control. If you're using ASTRO or any other language that gives you more control over how you load your JavaScript, make sure that you understand when you're using it, when you're loading it, and how you're loading it. If you even need to load it in the first place.

You can share state between islands very easily with stores. Nano stores is one example of that, but you can write your very own store with a few lines of JavaScript. And that's it. Thanks for listening. Please try out ASTRO. Try out fresh. Try out islands. Let me know what you think. Thanks very much.