Astro-style islands. Inside WordPress.
Atlas compiles type-safe components into deterministic manifests and
renders them server-side as a Gutenberg block. Motion-driven sections
hydrate as islands using the directives you know —
client:load, client:visible,
client:idle. Same model as Astro, one host.
What developers actually want from Astro.
Astro's reputation isn't an accident. Four properties teams reach for when they pick it — the same four most WordPress builds quietly lack.
A real component model.
Components are files in a repo. Props are typed. Composition is imports. You stop fighting the editor to express "this is one thing that takes these inputs."
Islands, not framework runtimes.
Static HTML by default. Hydrate one node, not the whole page. The browser receives bytes, not a JavaScript program that has to boot before anything is interactive.
Zero JS by default.
The page ships as HTML and CSS. No hydration tax on the marketing paragraphs, the footer, or the about page. JavaScript is opt-in per node, with a directive that says when it runs.
Type safety at the author seam.
Content collections, typed frontmatter, props the compiler checks against a schema. Misspell a field, miss a required prop, ship the wrong shape — the build fails before the page ships.
What you trade going pure Astro on top of WordPress.
The headless split — WordPress as the CMS, Astro as the front-end — is sometimes the right architecture. It also costs more than the diagram suggests.
Two codebases for every change.
A new content type means a CPT in WordPress, a query in Astro, a response type, a preview wiring, and a release in both deploys. The 10-minute change becomes the 90-minute change.
Preview is permanently broken.
WordPress's preview assumes WordPress renders the page. Wiring it to a separate Astro app means token exchanges, draft endpoints, and re-deploys. Editors stop trusting it and write in Google Docs.
The plugin ecosystem stops working.
Yoast, WooCommerce, forms, comments, caching — every plugin assumes it renders the page. On a decoupled Astro front-end, half of them break or need adapters. You re-implement the long tail by hand.
Two hosts, two on-calls.
WordPress for the admin, Vercel or Netlify for Astro, a CDN in front, sometimes an auth proxy. More surface area, more bills, more things that break at 3am.
How Atlas delivers each Astro property.
The Astro ideas survive the move into WordPress. The split doesn't have to.
Islands, same directives.
Mark a node with client:load,
client:visible, or client:idle. The plugin
renders everything else as HTML and hydrates only that node — GSAP
motion runs where you marked it, the rest stays static.
A real component model.
Components are TypeScript files. Atlas compiles them into a frozen tree of typed invocations with resolved props. Composition is imports, not block-editor nesting.
Zero JS by default.
Manifests render server-side as HTML. The browser receives the page, not a framework runtime that re-fetches its own data. What ships is what you marked as an island — nothing else.
Typed props at the author seam.
Atlas component props are TypeScript. The compiler catches missing fields, shape mismatches, and bad references before a manifest ships. The admin never sees broken data.
The same mental model, end to end.
An Astro component, the manifest Atlas compiles it into, and the HTML WordPress serves. Same directives because the idea is the same.
---
const { headline, lede } = Astro.props;
---
<section class="hero">
<h1>{headline}</h1>
<p>{lede}</p>
<Motion client:visible />
</section> {
"type": "Hero",
"props": {
"headline": "...",
"lede": "..."
},
"children": [{
"type": "Motion",
"island": "client:visible"
}]
} <section class="hero">
<h1>...</h1>
<p>...</p>
<div data-island="visible">
<!-- hydrates on scroll -->
</div>
</section> When pure Astro is still right.
Atlas is not a universal answer. Some builds want Astro on its own host; some want the headless split.
You don't need WordPress at all.
If the site is docs, a portfolio, or a marketing build with no editor-facing CMS, pure Astro is the right answer. Atlas earns its keep when WordPress is already on the bill.
You need the front-end on a different host.
Edge functions, regional compliance, or a marketing constraint can force the front-end off the WordPress host. Atlas renders inside WordPress; for those cases the headless tradeoffs are worth it.
Common questions.
Is Atlas a fork of Astro?
No. Atlas is a separate runtime — a Gutenberg block that
server-renders deterministic manifests inside WordPress. It borrows
the islands model and client:* vocabulary because they
are the right primitives for partial hydration.
Do I author components in .astro files?
No — Atlas components are TypeScript. The author-time API differs from Astro's single-file format, but the mental model (typed props, composition by import, opt-in hydration) maps directly across.
What runs the islands at runtime?
The motion runtime is GSAP. When the plugin renders a node marked
client:visible or client:idle, it ships
the minimum runtime for that island and triggers on the directive.
Nodes without a directive ship zero JS.
What WordPress version do I need?
WordPress 6.4+ and PHP 8.1+. Atlas registers a single dynamic block
(atlas/block); your theme, your other plugins, and
your hosting stay in place.
What happens if I deactivate the plugin?
The block degrades to a plain HTML snapshot of the last successful render. No proprietary shortcode debris in the post body, no broken page. Islands stop hydrating, the page stays readable, and you can leave or come back without rewriting the theme.
The dev experience, without the second stack.
Rebuild one page with typed components and islands, then measure. Match a standalone Astro front-end, and you just removed a host, a deploy, and a contract.