What Is Astro? A Beginner's Guide to the Web Framework

Astro is a web framework for content-driven sites. It renders your pages to HTML at build time and ships zero JavaScript unless you ask for some. That default is the whole point, and it is what sets Astro apart from React or Next.js.

To be clear about the word: this is Astro the JavaScript framework, not an astrology app. Developers use it for blogs, docs, and marketing sites. Draftbase pairs with it as the content layer, feeding entries over a cached API.

What Is Astro, Exactly?

Astro is a build tool and a rendering model in one. You write pages as .astro files, and Astro turns them into HTML.

The key part is what it leaves out. A typical React page ships a component tree, a runtime, and hydration code. An Astro page ships the HTML and nothing else, unless a component opts in. (Astro Docs)

That is why Astro pages tend to score well on loading metrics. There is no framework runtime to download, parse, and run before the content appears.

Astro is also not tied to one UI library. You can write components in React, Vue, Svelte, Preact, or plain HTML, and mix them in one project.

What Are Astro Islands?

An island is a live component sitting in an otherwise static page.

Picture a docs page. The prose, the nav, and the code samples are static HTML. The search box needs JavaScript. In Astro, only the search box becomes an island.

You mark it with a client directive:

---
import Search from '../components/Search.jsx';
---
<h1>Docs</h1>
<Search client:load />

That client:load tells Astro to hydrate this one component. Everything else on the page stays plain HTML.

Other directives change the timing. client:idle waits until the browser is free. client:visible waits until the component scrolls into view. A heavy widget below the fold costs nothing until someone scrolls to it.

This is called partial hydration, and Astro was the first mainstream framework to build it in by default. The effect is that JavaScript cost tracks the live parts of a page, not the page size.

What Does an Astro Page Look Like?

The file format is the fastest way to understand the model. An .astro file has two parts.

---
// This runs at build time, on the server. Never in the browser.
const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost', {
  headers: { Authorization: `Bearer ${import.meta.env.DRAFTBASE_KEY}` },
});
const { items } = await res.json();
---
<ul>
  {items.map((post) => <li><a href={`/blog/${post.slug}`}>{post.title}</a></li>)}
</ul>

The block between the dashes is the frontmatter script. It runs once, during the build. Your API key stays on the server, and the response never reaches the browser.

Below it is the template. It looks like JSX and compiles to plain HTML.

That split is the mental model. Code above the dashes runs at build. Markup below it becomes the page.

Can Astro Handle Dynamic Pages?

Yes, and this is where most beginner guides are out of date. They describe Astro as a static-only tool. That stopped being true.

Astro 5 merged the old static and hybrid output modes into one. Add an adapter and any single route can render on the server at request time, with no extra config. (Astro)

There is also a newer option that solves the awkward middle case. Server islands defer one block of a page until after the initial load.

The page itself stays static and CDN-cached. A user panel, a cart total, or a stock counter renders on demand and gets injected afterward. (Astro)

That matters more than it sounds. The old problem with static sites was that one personalized element forced the whole page to go dynamic. A server island keeps the fast cached page and scopes the dynamic work to the one block that needs it.

So the accurate summary is three modes, not one. Static by default. Server rendering per route. Server islands for a dynamic block inside a static page.

How Does Astro Handle Content?

Astro treats content as a first-class input rather than an afterthought.

Content collections give you typed, validated content with a schema. TypeScript types come from that schema for free. (Astro Docs)

Astro 5 widened this with the Content Layer. Collections can now load from APIs and databases, not just files on disk. (Astro)

The mechanism is a loader. It is a function that fetches data from a source and hands it to the content store. Local files, a headless CMS, or a database all work through the same interface. (Astro Docs)

The speed gains were real too. Astro reports content collections building up to 5x faster for Markdown and 2x for MDX, with memory use down 25 to 50 percent. (Astro)

For a CMS-backed site, this is the piece that matters most. Your CMS becomes a typed collection, and pages read it like any local file.

When Should You Pick Astro?

Pick Astro when the content is the product. Blogs, docs, marketing sites, and landing pages all fit cleanly.

Pick it when loading speed is a hard rule. Shipping no JavaScript by default is a bigger win than optimizing a bundle you did not need.

Pick it when your team knows more than one UI library, or none. Astro does not force a choice.

Skip Astro when the site is mostly an application. A dashboard with heavy shared state, live co-editing, or per-user routing on every page is a better fit for Next.js. Islands help when the live parts are scattered, not when they are everywhere.

Developer sentiment backs the content-site framing. Astro leads meta-framework scores by 39 points over Next.js. (State of JavaScript 2025) Read that as a tight match to its audience, not proof of a better tool for every job.

What Does Astro Need From a CMS?

Astro fetches content during the build, so the CMS must answer a server-side HTTP call.

Three things to confirm before you pair them:

1. A plain HTTP API with a server key, callable from the frontmatter script.
2. Webhooks on publish, so a new entry triggers a rebuild automatically.
3. A portable content format, so content survives a framework swap.

Draftbase covers all three. Content comes over a cached REST or GraphQL delivery API, webhooks fire on every entry event, and rich text is stored as plain MDX rather than a vendor tree.

MDX matters specifically for Astro. Astro renders MDX natively, so entries drop straight into a page without a conversion step.

Is Astro Hard to Learn?

Not if you have written any HTML. That is the honest answer.

The .astro file format is HTML with two additions. A script block at the top, and curly braces for values in the markup. If you have used JSX, it will read as familiar. If you have not, it reads like a template language.

The part that trips people up is the build-time boundary. Code in the frontmatter script runs once, on the server. It cannot respond to a click.

New users often expect a useState call in that block to work. It will not, because there is no browser there yet. That code belongs in a component marked with a client directive.

Once that clicks, the rest is small. Routing is file-based, so a file at src/pages/about.astro becomes /about. There is no router to configure.

Conclusion

Astro is a framework built around one bet: most sites ship far more JavaScript than they need. It renders HTML at build time, hydrates only the components you mark, and now handles dynamic routes and server islands when you need them.

That makes it a strong default for any site where reading is the main activity. Pair it with a CMS that can feed a build step and stay out of the way.

Draftbase serves MDX over a cached API with publish webhooks, so an Astro build can pull content and redeploy on its own. Hobby is free and Startup runs $49/mo. See the pricing page, or read how to choose a web framework if you are still deciding.