Astro & Fresh - Understanding the Islands Architecture

Hi, everyone. I want to talk about the islands architecture today. It is an emerging new way to build websites which enables you to build websites with low JavaScript or maybe even no JavaScript. The libraries at the forefront of this are Astro and Fresh. I will try to give a demo of Astro in this talk and we will explore how it implements the islands architecture.

But before we get there, I want to lay the groundwork for why something like the islands architecture exists and how we get to this point. So a little bit about me, my name is Arpit. You can find me online. I work in the Web 3.0 space for a DeFi protocol and let's get started.

So let's think about the kind of websites that we are used to building. We build blogs, documentations or very data driven applications, something like Facebook which has load a lot of data to display it to the user. So we can divide these out into two different kinds of websites which are content driven websites and data driven websites. Both of them have different kinds of needs and different types of scale that they are trying to achieve and we should try and use the correct tool for the job.

Between them, we have everything in between. So as I said content driven websites and data driven websites. But this is not an either or kind of thing. There are some websites which will have a lot of content on one page but the other page will be mostly static html and nothing else. So the reason I bring this up is we are used to building a lot of these with the same kinds of tools. And those tools are component libraries that have gotten very popular in the last decade or so. So the most popular is React but some of you may be using Vue, Swelt or SolidJs. The pros of these are that they are composable. You can combine them into multiple different components. You can reuse them throughout your application. Even in design systems, you can use similar types of components on different platforms even. They are usually easy to write, especially if you write them in small chunks. They are very easy to delete. The thing about these libraries is they are all client-side libraries. So they don't usually render anything on the server. Because of this, you end up giving an issue and search engines cannot easily index your websites. They also deliver a large JavaScript payload because you have to serve your own JavaScript along with the library itself.

Along with that, you don't serve any HTML. So you have all the downsides without any of the upsides. The big one is that there is a large contentful panel called LCP, which is slow. This means that it takes a very long time for the content to be visible to the users.

So the way we resolve this in the industry is to use server-side rendering. So all of these libraries have their own frameworks. React has Next, Vue has Nuxt, and all of them are building on something new. So the pros are that you render some part of your application as HTML, and serve that to the users. Data fetching can happen on the server. So with Next.js you can do data fetching once, when the application is built, or every time the user hits, which is what their getServerSideProps function does. It enables good SEO for you, because along with JavaScript you are also serving HTML, and it has faster LCP. One problem with this is you still serve a very large JavaScript payload that you may not really need to. These frameworks mostly rely on full page hydration.

What I want to talk about next is hydration. Hydration is basically serving an HTML page and along with that serving a JavaScript file and make it interactive. The HTML will show some data on screen or some content on screen while the JavaScript loads and after JavaScript loads, it will make your content interactive by adding event listeners, adding on click listeners, for example. Everything that you would do with JavaScript, this is what hydration is.

Right now, you would think of hydration as either no hydration or full page hydration. No hydration is just that your server renders some HTML and serves that to the users and that can get you pretty far. Just HTML and CSS will get you pretty far, but you do need some JavaScript later on. So the way these frameworks enable this is to load all of the JavaScript for the entire page at once and then the framework which you are using will load and take over the entire website and will be responsible for rendering, whatever rendering happens. So there is a middle ground between this which is partial hydration. So when you are writing a component based framework, you can think of it as some components which will load only HTML and some components which will load their JavaScript that they need along with the HTML. So what this enables you to do is create islands of interactivity. What this means is you will have multiple elements in your page which are responsible for loading their own data and this means that your app is basically a collection of many apps or many islands that load their own data and are responsible for rendering themselves basically.

So let's take an example for example and we have a basic layout for a website. You might have a header, text content image carousel, footer. So you probably don't need all of these to be rendered via React or something. You can render some of these on the server and you don't need to load the JavaScript for it at all. So you need to identify what part of your applications do not need JavaScript at all and then serve that basically. So for example, a header might have a search bar, sidebar might have some interactivity and image carousel will have onclick listeners on it. So they need some kind of JavaScript that they can load and there will be islands that will load JavaScript for themselves. And the footer and the main content text, that may not really need JavaScript. So it doesn't make sense to write a React component for them and load that JavaScript back to the user when they don't really need it.

So one example that I also want to give is Smashing Magazine. So look at this website. Everything here that you see can be rendered on the server and you probably don't need anything that needs to interact with it. Like all of these are links and that is a feature that clicking on links is a feature that the browser gives you for free basically. But input. If I search for async await here, this is running some kind of search query in the background and all of this is enabled by some JavaScript. You cannot get rid of it completely. So the ideal way would be to render all of this on the server and inject some kind of JavaScript. This search bar itself would be an island of interactivity where it loads only the JavaScript that it needs.

So that's partial hydration and that gets us to the implementation of the islands architecture and partial hydration. Among that, I want to talk about astro which is astro.build. This library is a framework for implementing the islands architecture. Let's run through a demo of it. How do we do this? Run the setup wizard. So pnpm create astro. Let's go. Let's call this test. Test is not empty. Wow. Let's call this test one. Let's just do the basics. Would you like to install? Let's not do that right now. No get repository. And I really like TypeScript so strict types. Cool. So I actually had already built an Astro demo for this. So let's go ahead and see what we get. Sorry, we want to see this in action. How do we run this. There are some scripts. Let's do the dev script pnpm dev. And sorry. Let's go to localhost. This is 3000. And we don't see anything yet. Why don't we see anything. So one thing about this, it follows the routing with page files, file based routing. So right now we see that we are not rendering anything. Let's see what happens when we render our hello component.

It says hi, I'm Arpit. How are you doing? Nice, let's explore what this hello component is. Also pay attention to what the file extension is. It is dot astro. So dot astro ships with its own component framework and component rendering model, basically. So you can execute JavaScript in this area right here, and below that will be a single file component that you can export and import in other component files basically.

So I want to render in H1 with the name, and this is JSX, just like React, as many of you might be familiar with. If I update this to something like this, updated, nice. As you might see, this is really fast, so it's nice that they implement fast refresh as well. One thing, so this JavaScript, where does it execute? It's printed hello here, but did it get printed here? It was not. So it looks like this Azure component only executes on the server. So you did not actually ship any of this JavaScript to the user. This gets converted into HTML and then shipped off to the user. This means you can use it like a template format, where you can do a fetch of ... Fetch something from your database, basically. And that would basically run it like PHP. There is a joke in the Astro community that Astro is just PHP, where you fetch all of your data here and render templates. And that is kind of true, really.

Let's look at some other examples. I want to build a counter, an interactive example of what should happen here. Let's comment this out. I want to build a react counter, which will basically just add a button and add an increment button and a decrement button. So, a simple example, useState, we will increment it with add, decrement it with subtract. And let's see what this does. In an astrophile, I can import React components. This is really kind of amazing. So, let's see how this works. Components, react counter, dot, do I need to? Probably not. Yeah. All right.

What happened? React counter. I'm clicking on it, but nothing is happening. Why is that? This is weird. Is this broken? No. So, the thing is, this is not a bug, this is kind of a feature, in Astro.build, we ship zero JavaScript by default. So, what does that mean? How do you enable JavaScript then? Because we are writing React, so, obviously, we want to ship JavaScript, it doesn't work without JavaScript.

So, by default, we see that it rendered whatever the output was, by default, what it would render on the server, we can enable JavaScript by these directives, these client directives. So, what is this client load? This means that JavaScript will load along with the page when the entire page loads. So, now if I click on it, it's working now. That's amazing, right? So, JavaScript only loads when you need it. So, it means there are other directives as well. Idle, it means as soon as it can start loading, basically. Media is, you can load JavaScript conditionally, if you are on mobile, it will only load that component on mobile, if you are on desktop, it will only load that component on desktop. This is the same thing as CSS variables. Then client-visible, it uses internally something called intersection observer to observe if the component is on screen or not, and if it is on screen, it will load the JavaScript only then. So, if you are building a very large landing page, for example, and you have to keep scrolling and scrolling, but you also want the landing page to load very quickly, so you can enable something like this where the HTML would load and render very quickly, and the JavaScript will progressively load when the component enters the viewport. So, we want to keep it at load for now.

So, another thing about Astro is it is a multi-component framework, as you might have seen, solid component and a swelled component here. So, yeah, let's see how that works. You can render multiple of these components in Astro, even in the same file, actually. Let's see how this happens, by the way. So, astro.config, we are loading React and Tailwind here. As you might have noticed, I'm using Tailwind here. So, this makes it so that Astro can deal with React components and Tailwind components. So, let's see how these integrations work. Astro has integrations for all of these frameworks, alpinejs, lit, preact, vue that we are not covering here. But, let's see how we add these. So, npx astro add-react, okay. I have a solid component and a swelled component written out here. Let's see if we can add this.

Astro add, let's see if we can add multiple of these. Solidjs and swelled. Let's go. Yep, yes, ya, see how intelligent this was. So it added solidjs and swelled to our config automatically when we did an astro add. So let's look at a solid component here.

Solidjs is just very close to react. So we create a signal. We create an add function and a subtract function and this will look almost exactly the same thing, except the counter will be a function call. And let's see. Oh, we did not import it. Let's import this. Solid counter. See how amazing this is. We are running a React component and a solid component in the same page. Let's go ahead one step further.

This is a swelled component as well that I wrote. Same thing, an add function, a subtract function, we just increment differently here, attach our on click handlers, and import, let's say solid. Why are multiple libraries an impressive thing? So, imagine if you are building on a really large application, where multiple teams are working on different kinds of applications, and they have different needs, so they could really be working on two different projects, and one team wants to use React and one team wants to use Solid, and they could theoretically do that, well, actually do that now, and same thing with any other framework, and say if you want to slowly migrate away from React-based code base to a Solid-based code base, you could progressively replace each and every component that you have and move onto a different framework, basically. Yeah, so this is SolidJS. This is ReactJS. This is SwellJS. In the same thing, enabled by AstroJS, and that is it.