React, Vue, Svelte, Angular, and Next.js all share one assumption underneath their real differences: the browser gets a JavaScript runtime, and the page is treated as an application. Astro starts from a genuinely different assumption — most of a real page is content, not application state, and the framework's own default output is plain, static HTML with no JavaScript shipped at all, unless you deliberately ask for some.

Zero JavaScript by Default

Every Astro component renders to plain HTML at build time — including components written in React, Vue, or Svelte and used inside an Astro page. Unlike Next.js, where a React component ships its own JavaScript to the browser and hydrates automatically, an Astro page with ten components on it can ship zero bytes of framework JavaScript by default. Nothing hydrates unless it's told to.

The Islands Architecture

Astro's own name for this model is the islands architecture: picture a page as a mostly static "ocean" of plain HTML, with small, isolated "islands" of interactivity dropped in only where genuinely needed — a like button, a search box, a carousel. Each island hydrates independently, on its own schedule, rather than the whole page hydrating as one unit the way a client-rendered React or Vue app does.

Why "Content-First"?

Astro was built with blogs, documentation sites, marketing pages, and portfolios in mind — sites where the overwhelming majority of the page is content that never changes after it's rendered, and only a handful of small pieces are genuinely interactive. That's a real, different sweet spot from a framework built assuming the whole page is one interactive application from the start.

Four Frameworks, One New Assumption

Creating a Project

The scaffolding wizard offers a few starter templates — an empty project is the clearest one to learn from. npm run dev starts the dev server with live reload, the same as every other framework in this series.

• src/pages/ — every file here becomes a real page, by convention (Chapter 3)
• src/components/ — reusable .astro components
• src/layouts/ — shared page shells (Chapter 4)
• astro.config.mjs — the project's own configuration file

Coding Challenges

Every .astro file has two parts: a frontmatter fence at the top for plain JavaScript or TypeScript, and a markup section below it. Both parts behave differently from every sibling framework in this series in ways worth understanding precisely, not just by analogy.

The Frontmatter Fence: Runs Once, Not Reactive

The code between the two --- lines runs exactly once — at build time for a static page, or once per request in server-rendered mode (Chapter 10) — and never again after that. There's no re-run on the client, because by default there's no client-side runtime at all. This is a genuinely different mental model from Svelte's own reactive <script> block, which re-runs logic in response to state changes in the browser.

Markup Expressions: JSX-Style, Not a Directive Language

Astro's own markup expressions — { } — contain real JavaScript expressions, evaluated directly: .map() for lists, && or a ternary for conditionals. This is genuinely closer to React's JSX than to Vue's v-for/v-if directives or Svelte's own {#each}/{#if} block syntax — Astro doesn't introduce a separate template directive language at all; the markup expressions are JavaScript.

Props via Astro.props

An optional interface Props gives typed, self-documenting props — genuinely useful in TypeScript projects, and entirely optional. Destructuring Astro.props in the frontmatter is the direct equivalent of a React function component's own props parameter.

Multiple Root Elements — No Wrapping Fragment Needed

Astro components can have multiple top-level elements natively — there's no historical single-root-element rule to work around the way early React needed <Fragment>/<></> for. Vue 3 and Svelte both allow this too; it's React's own older constraint (long since solved by Fragments) that made this worth calling out explicitly.

Frontmatter and Markup, Compared Across Frameworks

Coding Challenges

Chapter 1 briefly showed a plain static file in src/pages/ becoming a real route. This chapter covers the rest of the picture: dynamic segments, catch-all routes for arbitrary-depth paths, and the one real constraint every dynamic route runs into by default — getStaticPaths().

Static Routes, Recapped

• src/pages/index.astro → /
• src/pages/about.astro → /about
• src/pages/blog/index.astro → /blog

Folders nest naturally into path segments — no route configuration file exists anywhere in an Astro project.

Dynamic Single-Segment Routes

[slug].astro matches any single path segment at that position — /blog/first-post, /blog/second-post — captured into Astro.params.slug.

Catch-All Routes: Arbitrary-Depth Paths

[...path].astro is Astro's own catch-all segment — the three dots match zero or more path segments, slashes included, all captured into a single string on Astro.params.path. Same requirement applies: every real deep path this route should serve has to appear in getStaticPaths()'s own returned list.

No Client-Side Router by Default

Unlike a single-page application framework, Astro doesn't ship a client-side router at all by default — navigating between pages is a genuine full page load, since there's no persistent client-side app to route within. An optional View Transitions API exists for smoother navigation animations, but it's a later, opt-in refinement, not a default routing mechanism the way React Router or Vue Router are.

Coding Challenges

Every page written so far has repeated its own <html>/<head>/<body> boilerplate. A layout is just an ordinary Astro component, conventionally kept in src/layouts/, that wraps a page's own content instead.

A Basic Layout

Whatever's placed between <BaseLayout> and </BaseLayout> in the page renders wherever <slot /> appears inside the layout itself. title is passed as an ordinary prop, same as any other component — a layout isn't a special kind of file, just a component used in this particular role by convention.

Named Slots

An element with a slot="name" attribute is routed into the matching named <slot name="..." />; everything else falls into the unnamed default slot.

Nesting Layouts

A layout can wrap another layout — BlogPostLayout adds blog-specific chrome (a publish date) around its own <slot />, while still passing through to BaseLayout for the shared <html> shell. Layouts compose the same way any other Astro components do.

Slots, Compared Across Frameworks

Coding Challenges

Astro's own answer to "structured, validated content" is Content Collections — a real, first-class feature for organizing Markdown/MDX content into typed, schema-validated groups, kept in src/content/.

Defining a Collection

The schema is a real Zod object — Zod is a popular TypeScript-first schema validation library, used here to declare exactly what fields every entry's own frontmatter must have, and of what type. Every Markdown file in src/content/blog/ gets validated against this schema.

Reading a Collection: getCollection()

getCollection('blog') returns every entry in the collection, each with a validated, typed data object matching the Zod schema above.

Rendering a Single Entry — Connecting Back to getStaticPaths()

Chapter 3's own getStaticPaths() can return a props object alongside params — whatever's passed here becomes directly available as Astro.props in the page, avoiding a second lookup. post.render() returns a real <Content /> component rendering that entry's own Markdown body.

Coding Challenges

A <style> block inside an .astro component is scoped to that component automatically — no explicit keyword needed, matching Svelte's own zero-config default rather than Vue's opt-in scoped attribute.

Scoped by Default

Astro adds a unique attribute to this component's own elements at build time, so a different component's own .card rule never collides with this one — the identical technique, and the identical zero-runtime-cost result, Svelte's own scoped styles already used.

Opting Out: is:global

is:global on a specific <style> block disables scoping for just that block, letting its rules apply site-wide from wherever the component happens to be used.

A Real Site-Wide Stylesheet

For genuinely site-wide styling — this project's own established dark theme, for instance — a plain imported .css file in a shared layout's frontmatter is the natural choice, applying unscoped to the whole page.

define:vars: Frontmatter Values Inside CSS

Sass Support, Out of the Box

Installing the sass package is the only setup required — no bundler configuration to write. lang="scss" on any <style> block enables real Sass syntax, still scoped by default the same as plain CSS.

Scoped Styles, Compared

Coding Challenges

Chapter 1 claimed Astro ships zero JavaScript by default. Here's where that claim gets paid off concretely: client directives are the only mechanism that opts an individual component into hydration — without one, even a React or Svelte component renders to static HTML and nothing more.

No Directive: Static HTML, No Exceptions

Even though Counter is a real React component with its own useState, without a client directive it's treated exactly like any Astro component: rendered once to HTML, then discarded. Clicking the button does nothing.

The Five Client Directives

• client:load — hydrates immediately once the page loads. For genuinely critical, above-the-fold interactivity.
• client:idle — hydrates once the browser's main thread goes idle (via requestIdleCallback). For interactivity that matters but isn't urgent.
• client:visible — hydrates only when the component scrolls into the viewport (via IntersectionObserver). Ideal for anything below the fold.
• client:media="(query)" — hydrates only when a CSS media query matches — a mobile-only menu, for instance, that never hydrates at all on desktop.
• client:only="react" — skips server rendering entirely, rendering only in the browser. For components that depend on browser-only APIs that would error during the build.

Choosing the Right Directive

Coding Challenges

This chapter builds directly on this site's own existing react1–react4, vue1, and svelte1 courses — it covers the integration boundary between Astro and those frameworks, not the frameworks' own syntax, which those courses already teach in full.

Adding a Framework Integration

npx astro add [framework] installs the needed packages and wires up astro.config.mjs automatically.

Using a Framework Component

Props are passed as ordinary attributes, the same as any Astro component. Each framework's own file extension (.jsx/.tsx, .vue, .svelte) is imported directly — no wrapping needed.

A Real Constraint: Props Must Be Serializable

A Second Real Constraint: No Direct Cross-Framework Nesting

A React component cannot directly contain a Vue component as a JSX child, and vice versa — the two framework runtimes don't compose that way. Composition across frameworks happens at the Astro layer instead: an Astro component can wrap a framework island and use <slot /> (Chapter 4) to let Astro-level content — including other framework islands — surround it.

Both islands sit side by side inside Panel's own <slot /> — real, valid composition, achieved entirely at the Astro layer rather than one framework component containing the other directly.

Coding Challenges

There are three genuinely different ways to get data into an Astro site, each with its own timing and tradeoffs.

Fetching in the Frontmatter: Build Time, Not Request Time

API Endpoints

Any file in src/pages/api/ exporting a named GET (or POST, PUT, etc.) function returning a real Response becomes a working API endpoint — here, reachable at /api/posts.json. In static output mode, this endpoint is also generated once at build time, the same constraint as the frontmatter fetch above; Chapter 10's server/hybrid modes are what let an endpoint like this run fresh on every request instead.

Client-Side Fetching Inside an Island

A hydrated island (Chapter 7) can fetch data itself, in the browser, at runtime — genuinely fresh every time the component loads, regardless of when the site was last built. The real cost is exactly what Chapter 7 already established: this requires shipping and hydrating real client-side JavaScript, unlike the frontmatter fetch's zero-JS static output.

Three Approaches, Compared

Coding Challenges

Every earlier chapter used Astro's default: output: 'static'. This chapter covers the other side — output: 'server', and mixing both per page — which removes several constraints already flagged along the way, including Chapter 1's own promise that Astro "isn't only for static blogs."

Static Output — the Default, Recapped

Every page pre-rendered to plain HTML files at build time. getStaticPaths() (Chapter 3) is required for any dynamic route, since every possible path has to be known up front — there's no server running afterward to resolve one on demand.

Server Output: Per-Request Rendering

output: 'server' renders every page fresh, per request. Astro itself doesn't ship a production server runtime — an adapter (@astrojs/node, @astrojs/vercel, @astrojs/netlify, and others) is what actually runs the server on a given platform, installed via npx astro add node.

Mixing Both: Per-Page Opt-Out

A single page can opt out of the project's own default mode via export const prerender — a mostly-static project can mark one genuinely dynamic page (a live dashboard, an admin panel) for server rendering, while everything else stays pre-built and fast. The reverse works too: in a server-output project, a page that's genuinely static (a privacy policy, an about page) can be marked prerender = true to skip per-request rendering for content that never changes.

Three Rendering Approaches, Compared

Coding Challenges

Chapter 5 covered Content Collections as a structure. This chapter covers what actually goes inside them — plain Markdown for the vast majority of content, and MDX for the real, specific case where a piece of content needs a live, interactive component embedded directly in the prose.

Plain Markdown

Standard Markdown syntax — headings, lists, fenced code blocks — renders exactly as expected. Fenced code blocks get real syntax highlighting automatically, via Astro's own built-in Shiki integration — no separate highlighting library or configuration needed, unlike many other static site tools.

MDX: Markdown with Embedded Components

.mdx files allow real import statements and real component tags directly inside otherwise-plain Markdown prose — requires the @astrojs/mdx integration (npx astro add mdx).

Mixing .md and .mdx in One Collection

A single Content Collection can contain both .md and .mdx files side by side, as long as every entry — regardless of extension — satisfies the same Zod schema defined in src/content/config.ts (Chapter 5). getCollection() returns both kinds of entries together, with no special handling needed to distinguish them.

Markdown vs. MDX, Compared

Coding Challenges

This capstone builds one real, working blog — every earlier chapter contributes a real, working piece of it, not just a concept in isolation.

The Content Collection

Both zero-js-by-default.md and live-demo-post.mdx satisfy this same schema (Chapters 5 and 11).

Listing & Rendering Posts

This is Chapter 3's own getStaticPaths() pattern and Chapter 5's own props-passing shortcut, working together exactly as designed.

An Island for the Newsletter Signup

Placed on the blog index below the fold via <NewsletterSignup client:visible /> — Chapter 7's own genuine performance payoff: its JS never even downloads unless a visitor scrolls that far.

The API Endpoint — and Why It Forces a Rendering-Mode Decision

A real newsletter signup has to accept whatever email a visitor types, at the moment they submit it — exactly the case Chapter 10 identified as needing server output, not a static build. So the finished project's config reflects that decision:

Every Chapter's Own Contribution

Coding Challenges