An introduction to the emerging islands architecture which can significantly improve the performance of your apps.
Astro & Fresh - Understanding the Islands Architecture
FAQ
Islands architecture is an emerging way to build websites that enables developers to build sites with low or no JavaScript. It involves creating multiple interactive components (islands) that load their own data and JavaScript independently, thus improving performance and user experience.
The libraries at the forefront of the islands architecture are Astro and Fresh.
Both content-driven websites and data-driven websites can benefit from islands architecture. It allows for efficient handling of different needs and scales by using the correct tool for the job.
Client-side libraries often result in large JavaScript payloads, slow contentful paint (LCP), and difficulty with SEO because they do not render anything on the server by default.
Server-side rendering improves web performance by rendering parts of the application as HTML on the server, which enhances SEO and reduces the time it takes for content to be visible to users (faster LCP).
Hydration is the process of serving an HTML page along with a JavaScript file that makes the content interactive. The HTML displays the content while the JavaScript loads and adds interactivity such as event listeners.
Partial hydration involves loading only the necessary JavaScript for specific components (islands of interactivity) on a page, rather than the entire JavaScript for the whole page. This approach improves performance by reducing the amount of JavaScript loaded.
Astro uses a .astro file format that allows developers to fetch data and render components on the server. It supports multiple frameworks and enables developers to import components from React, SolidJS, and Svelte, among others. Astro ships zero JavaScript by default and uses directives to load JavaScript only when needed.
Client directives in Astro are used to control when JavaScript should be loaded. Examples include client:load (loads JavaScript with the page), client:idle (loads JavaScript as soon as possible), client:media (conditionally loads JavaScript based on media queries), and client:visible (loads JavaScript when the component enters the viewport).
Astro's multi-component framework support allows developers to use components from different frameworks (e.g., React, SolidJS, Svelte) in the same project. This is beneficial for large applications where multiple teams might use different frameworks or for progressively migrating from one framework to another.
Video Summary and Transcription
1. Introduction to Islands Architecture
The islands architecture is an emerging new way to build websites with low or no JavaScript, using libraries like Astro and Fresh. These websites can be divided into content driven and data driven websites, each with different needs and scale. Component libraries like React, Vue, Swelt, and SolidJs have become popular for building these websites, offering composability, reusability, and easy deletion. However, they are client-side libraries, which can cause issues with search engine indexing and result in large JavaScript payloads.
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.
2. Server-side Rendering and Downsides
The downsides of not serving HTML are that it results in slow loading times and a large contentful panel called LCP. To resolve this, server-side rendering is used, with frameworks like Next.js and Nuxt. Server-side rendering allows you to render some parts of your application as HTML, improving SEO and reducing loading times. However, it can still result in serving a large JavaScript payload.
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.
Check out more articles and videos
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Workshops on related topic
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Comments