Writing at Astro v6 Beta: Astro Lets Real Websites Embrace the Modern Frontend Ecosystem

This article was translated by AI and has not been manually reviewed.

Componentization Does Not Necessarily Require JavaScript

In the modern frontend, one core value provided by almost all mainstream frameworks is "componentization". Frameworks such as React/Vue let us split UI into individual components, then run this component logic uniformly in the browser: create virtual DOM, diff, and update the view. But do not forget that the problem these frameworks originally set out to solve was not componentization, but state and view management.

Componentization did originate from client-side JavaScript frameworks (React/Vue), and web standards followed up with the Web Components specification. But Web Components still rely heavily on JavaScript executed on the client to provide interaction logic. It is obvious, however, that the componentization development paradigm itself has nothing whatsoever to do with the rendering method.

So here comes the question: how can static or traditional server-first websites also gain componentization capabilities? React and Vue both have SSR capabilities, but many websites do not need such a heavy client runtime. So we have Astro.

Astro outputs static HTML by default and only loads JS when necessary. It starts from a different perspective: put componentization in a server-first context, and let JavaScript run only when necessary. In the world Astro depicts for us, ideally most pages send no JS by default, and interactive components enable JS on demand. This strategy is especially suitable for blogs, documentation, official sites, and showcase websites, making first-screen loading faster and metrics better.

Islands Architecture: Partial Hydration

One of Astro's most important ideas is Islands Architecture, which brings partial hydration.

First, review SSR and hydration in React and Vue. Traditional single-page applications (SPAs) hydrate the entire page's component tree on the client, initializing the client state of the entire page. But in many content-driven pages, such as blog posts and documentation pages, the content barely needs interaction logic running in the browser. Bringing a heavy runtime to such an entire page just to use some build-time capabilities of a framework (e.g. componentization) is completely unnecessary.

It is obvious that for a blog written in Next.js, hydrating the article area with React once has no meaning at all.

Astro's Islands Architecture:

• The whole page is presented as static HTML
• Only components that need interaction ("islands") are hydrated in the browser
• Islands from different frameworks (React, Vue, Svelte, Solid, etc.) can coexist on the same page

For example, the article part is all static HTML; only parts that need JS, such as like buttons and comment forms, load a runtime separately. This partial hydration model significantly reduces first-screen JS size without sacrificing the componentized development experience. Partial hydration lets us use different UI frameworks on the same page: React / Vue / Svelte / Solid can all coexist on the same page.

Perhaps this can be understood another way: Astro extracts the "build-time" part from traditional full-stack application frameworks and provides it separately, without bundling its own client library. These things were never strongly related to the client in the first place.

Meta-Framework Without the Frontend

SSR and On-Demand Rendering

Astro supports both static site generation (SSG) and SSR (Astro officially calls this on-demand rendering). Astro's SSR is not very different from traditional SSR, and it is also working hard to support more Serverless environments.

This refactor enables Astro to:

• Run against real runtimes – Development can execute inside the same runtime as production.
• Support more platforms – Cloudflare Workers today, with a foundation that supports additional runtimes in the future.

--https://astro.build/blog/astro-6-beta/

However, after static HTML is output by default, there is no need and no way to hydrate and activate it again. Static HTML is already the final product.

Server Actions and Backend Capabilities

Just now I said Astro extracts the "build-time" part from traditional full-stack application frameworks and provides it separately. In fact, Astro also provides the "server-side" part completely: SSR and Server Actions are all available and can be used on demand.

Astro's Server Actions and backend capabilities are almost the same as those of other full-stack frameworks. It provides a way to write backend RESTful API endpoints and rpc-style frontend-backend interaction. Of course, to send requests, Astro also has to introduce client JavaScript, but simply sending a request to verify a result still requires far, far less JavaScript than fully handling the UI view.

API endpoints: add .js or .ts files to the /pages directory and export HTTP method functions (such as GET, POST, etc.). In static mode, endpoints generate static files at build time; in SSR mode, endpoints become live server endpoints.

Actions system (Astro 4.15+): provides type-safe backend function definition and invocation. Actions use Zod to automatically validate input and generate type-safe client invocation functions without manually calling fetch(). Actions also support submission through HTML forms (zero JavaScript), providing complete form validation and error handling capabilities, which is very friendly for progressively enhanced web applications.

Making Full Use of the Existing JS Ecosystem

Use of Vite Environment API

The most significant change in Astro 6 is its completely redesigned development server. Through internal refactoring, it uses Vite's Environment API, narrowing the gap between development and production environments. In the past, code that worked normally in local development might behave differently after deployment. Platform-specific features were often impossible to test before deployment, and Astro even needed to maintain different code paths for "development" and "production", increasing the risk of edge-case bugs.

By using Vite's Environment API, Astro can now run the development server in the same runtime as production: the same JavaScript engine, the same global variables, and the same platform APIs. This change makes Astro 6 more stable and reliable across all runtimes, including non-Node.js environments.

Use of Vite Build Capabilities

Besides the Environment API, Astro also makes full use of Vite's many capabilities, including on-demand module compilation and HMR, a rich plugin ecosystem, and out-of-the-box build optimizations such as tree-shaking.

Astro's build process is deeply integrated with Vite. In the first phase of the build, Astro modules are JavaScript modules inside the Vite build process, parsed by Astro's plugin. After the Vite build is complete, Astro then executes its own build logic to generate HTML. For real "websites" -- portals, news sites, blogs -- rather than apps built with web capabilities, Astro also allows them to enjoy the rich modern frontend ecosystem.

Use of Modern Frontend Frameworks

Astro's Islands Architecture allows multiple frameworks to be mixed in the same project, and each interactive component can choose the most suitable framework. In this sense, one could say Astro is the framework with the richest ecosystem (laughs). But after laughing, it must be said that intuitively, the Astro official site probably does not want to encourage embedding a bunch of frameworks into a page. The Islands Architecture can greatly reduce the amount of hydration work, but it cannot change the size of the JS Bundle. Every embedded framework means downloading that framework's runtime locally. There is no way around that.