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 web3 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 to load a lot of data to display 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're 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, Svelte 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 system, 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. And they are very easy to delete. So the thing about these libraries is they are all client side libraries. So they don't usually render anything on the server. So because of this, you end up giving an SEO. So search engines cannot really easily index your websites. They also deliver a large JavaScript payload because you have to serve your own JavaScript code along with the library itself, and along with that, you don't serve any HTML. So you have all the downsides without any of the upsides really. And the big one is there is a large contentful pane, which is called LCP, which is slow, which means 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. But one problem with this is you still serve a very large JavaScript payload that you may not really need to. And these frameworks mostly rely on full page hydration. So that's what I want to talk about next. What is hydration? Hydration is basically serving an HTML page and along with that, serving a JavaScript page, JavaScript file, sorry, and make it interactive. So 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 listener, for example, everything that you would do with JavaScript. So this is what hydration is. So right now you would think of hydration as either no hydration or full page hydration. No hydration is just that you server end some HTML and serve 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're 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're writing a component-based framework, you can think of it as some components which will load only HTML and some components which will load the 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. 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 by a 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, a 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 React components 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. 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, so 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. So among that, I want to talk about Astro, which is astro.build. So this library is a framework for implementing the islands architecture and yeah, let's run through a demo of it. How do we do this? Run the setup result. So PNPM create Astro. 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 Astro 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 into your in other component files basically. So I want to render an H1 with the name. And this is JSX just just like React as many of you might be familiar with. If I update this to something like this updated nice and 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. This printed hello here. But did it get printed here. It was not. So it looks like this component only executes on the server. So you did not actually ship any any of this JavaScript to the user. This gets converted into HTML and then shipped off to the user. So great. And this means you can use it like a template format where you can fetch do a fetch of fetch something from your database basically. Fetch something from database here and that would basically run it like PHP. There is a joke in the community that Astro is just PHP where you fetch all of your data here and render templates. And that is kind of true really. So let's look at some other examples. So I want to build a counter or an interactive example of what should happen here. So 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 simple example you state. We will increment it with add decrement it or subtract. And let's see what this does. So in an Astro file I can import React components. This is really kind of amazing. So let's see how this works. Components React counter. Do I need to? Probably not. Yeah. I'll just do it. All right. What happened? So 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 zeo 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 on the by default it would 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. So when JavaScript only loads when you need it. So it means there are other directives as well. It means as soon as the main as soon as it can start loading basically. The idea is you can load JavaScript conditionally if you're on mobile it will only load that component on mobile. If you're on desktop it will only load that component on desktop. This is the same thing as CSS variables. Then client visible. Client visible will be it uses internally is 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're 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 swelt 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, React, Vue that we are not covering here. But let's see how we add these. So npx Astro add React. I have a solid component and a swelt component written out here. Let's see if we can add this. pnpn Astro add. Let's see if we can add multiple of these. Solid JS and swelt. Let's go. Yep, yes, yeah, see how intelligent this was. So it added solid JS and swelt to our config automatically when we did an Astro add. So let's look at a solid component here. Solid JS 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 swelt component as well that I wrote. Same thing, an add function, a subtract function. We just increment differently here. That's our onclick handlers and import solid, oh, not solid, sorry. So swelt count from component and right. Amazing. So why are multiple libraries an impressive thing? So imagine if you're 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 kinds of 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 on to a different framework basically. Yeah, so this is solidjs, this is reactjs, this is sweltjs in the same thing enabled by astrojs. And that is it. Goodbye.