Learning Astro - Core Concepts & Main Architecture

#Introduction

In episode 1 you learned why Astro exists and what problem it solves. Now it is time to open the hood and see how it works behind the scenes. Understanding Astro's architecture will make you far more confident when building real projects — you will know why a pattern works and why another pattern produces a large bundle.

Astro's architecture has four pillars: the compiler that turns .astro syntax into JavaScript, the build pipeline based on Vite, a rendering model that separates static and server, and the island architecture that keeps JavaScript shipped only to the parts that are truly interactive.

This episode 2 dissects all four pillars along with the project structure that will become your navigation map throughout the series.

#How It Works Behind the Scenes

#The Astro Compiler and the Vite Build Pipeline

.astro files are written in a syntax that resembles HTML with frontmatter added. Astro transforms these files through the Astro compiler into two things: a render function that produces HTML and — when needed — a client component for hydration.

The build pipeline is run by Vite: Vite collects all modules, optimizes dependencies, and produces the dist/ output. The dev server is also handled by Vite, so file edits are immediately visible without waiting for a full build. Here is the short flow:

src/*.astro → Astro compiler → Vite bundler → dist/ (HTML + assets)

The npm run build process runs this entire pipeline. The dist/ output is a static folder ready to be uploaded to any hosting.

#Page Rendering: Static and Server

Astro supports two main modes. In static rendering, a page is rendered once at build time and stored as an HTML file. In server rendering, a page is rendered on every request. Astro's default is static, and episode 21 will cover the hybrid mode that combines both.

#Island Architecture and Component Hydration

#The Interactive Island Concept

Island architecture is the idea that a large HTML page can contain a few interactive "islands" surrounded by a sea of static HTML. Each island is a framework component hydrated independently — with one small JavaScript file per island, not one giant bundle for the whole page.

#How Components Work

An important concept that sets Astro apart from other frameworks:

• Components without a directive are rendered as static HTML, with no JavaScript in the browser.
• Components with a hydration directive like client:load get the JavaScript needed to run their interactivity.

The hydration directive determines when and how the island is turned on — full details are in episode 7.

An interactive island among static HTML

---
import GaleriFoto from "../components/GaleriFoto.vue";
---
 
<main>
  <p>Paragraf statis ini tanpa JavaScript sama sekali.</p>
  <GaleriFoto client:visible />
  <p>Konten lain tetap statis, hanya pulau yang di-hydrate.</p>
</main>

In the code above, <GaleriFoto client:visible /> only loads JavaScript when that element becomes visible on screen — the rest of the page stays light.

#Main Components and Project Structure Workflow

#The Role of the Main Directories

An Astro project structure has clear rules:

• src/pages: .astro, .md, or .mdx files here become page routes.
• src/components: where components reused across many pages live.
• src/layouts: reusable layouts that wrap many pages.
• public/: static files like favicons and images copied as-is into the output.
• src/content: Markdown/MDX content along with its schemas.

#File-Based Routing

Routing in Astro follows the folder structure. The file src/pages/blog/index.astro becomes /blog, and the file src/pages/blog/[slug].astro becomes a dynamic page based on the URL parameter. There is no separate router file — just place files in the right folder.

#Content Collections and the Markdown Pipeline

Content collections are Astro's way of managing content with type safety. Every collection has a schema that defines the allowed frontmatter. At build time, Astro validates all content against the schema and produces structured data ready for pages to consume — we will dissect this pipeline fully in episode 5.

#Integrating Other Frameworks

#Installing Official Integrations

Astro can host components from React, Vue, Svelte, and Solid. The way to do it is to add an official integration:

npx astro add react

The npx astro add react command installs the package, edits astro.config.mjs, and prepares tsconfig.json for JSX. After that, .tsx components can be used directly inside .astro files.

#One Page, Many Frameworks

Because every integration is independent, a single Astro page can use Vue components for one island and Svelte for another. This is flexibility that most other meta-frameworks do not have, and it is precisely Astro's strength for cross-technology teams.

#Conclusion

Episode 2 opens up Astro's core architecture: the compiler that transforms .astro syntax, the Vite-based build pipeline, the static and server rendering models, island architecture for partial hydration, a simple project structure, and the flexibility of multi-framework integration.

The key takeaways:

• The Astro compiler turns .astro files into render functions and assets.
• Vite handles bundling and the dev server with HMR.
• Static rendering is created at build time; server rendering is created per request.
• Island architecture hydrates components independently.
• src/pages determines routes, public holds static assets.
• Framework integrations are installed with npx astro add <framework>.

In the next episode 3, we will start an Astro project for real: creating a project with npm create astro@latest, understanding the important file structure, running the dev server, and basic TypeScript, ESLint, and formatting configuration. Get your terminal ready, because this episode is full of hands-on practice.