Skip to content
Frontend7 min

Astro 5 in production: what we learned shipping a custom book platform

Why we chose Astro over Next.js, where it surprised us, and the call we'd make differently.

Astro 5 in production: what we learned shipping a custom book platform

Astro 5 is what you reach for when you don't need React on the client. We shipped a content-heavy book launch platform with Astro, hand-written CSS tokens, and zero JavaScript on most pages.

Here's the call we made, where it held up, and where we'd reach for something else next time.

Why Astro over Next.js or Hugo

The brief was a 11-page content-heavy launch site: long-form reading, custom typography, no auth, no real interactivity beyond a few menu transitions. Next.js would have shipped a JavaScript runtime on every page for no reason. Hugo would have meant giving up the JSX templating we wanted.

Astro hits the middle: server-rendered HTML by default, React (or Vue, Svelte, Solid) available as Islands when you actually need interactivity, JavaScript shipped only for those islands. For this brief, ~95% of pages shipped zero JavaScript and First Contentful Paint dropped below 800ms on 4G.

View Transitions API in real conditions

Astro's `<ViewTransitions />` directive gives you cross-page transitions for free where the browser supports it (Chrome, Edge, Safari 18+). We used it for a chapter-list-to-chapter transition and it was the kind of subtle polish that makes a site feel native.

The fallback for non-supporting browsers (~12% of our traffic) was clean — instant page loads, no transition. The one quirk: `transition:persist` for elements that should survive navigation needs identical DOM identity, and a tiny structural change in the source elements breaks the persistence silently.

CSS tokens by hand

We deliberately didn't use Tailwind. The brief was for a hand-crafted aesthetic where typography, spacing, and colour decisions would be specific to the book's world — not snapped to a utility framework's grid.

225+ CSS custom properties as tokens, organised by domain (typography, colour, spacing, motion). What we'd reuse next time: the token structure. What we wouldn't: hand-writing every utility — for anything beyond bespoke marketing sites the maintenance cost outweighs the aesthetic flexibility.

Cloudflare Pages vs Vercel

Both work. Cloudflare Pages is faster CDN globally (notably better in South Africa than Vercel's edge), Vercel has the better DX for Next-style features and the better preview-deploy experience.

We picked Pages for the cost story (free tier covers the project's lifetime traffic) and the SA latency. We'd pick the same again for an Astro project; for a Next.js project leaning on Vercel-specific features, the answer flips.

Where Astro hurt

No first-class image-optimization story comparable to Next 16's `next/image`. The third-party Astro Image component works but it's third-party.

Anything app-like — search, filters, multi-step forms — pushes you into React Islands and the JS bundle starts adding up. At that point you're paying Next-shaped costs without Next's tooling around them.

The TypeScript DX in `.astro` files is still rough. IntelliSense gets the templating right most of the time and wrong some of the time. We worked around it by keeping logic in `.ts` files and importing into `.astro` for templating only.

For content-heavy sites without significant interactivity, Astro 5 wins on bundle size, initial-load performance, and developer focus. We'd reach for it again — book sites, marketing sites, documentation sites, blogs.

For anything app-like — auth, real-time, complex forms, SaaS dashboards — we'd default to Next 16 and accept the runtime overhead. It's the right tool when interactivity is the point. Astro is the right tool when content is.

Working on something like this?

We build production software for teams whose problems don't fit a template. Tell us what you're working on — we'll tell you how we'd build it.

Start a conversation