Why We Ditched Next.js for Astro
Next.js was shipping hundreds of kilobytes of client JavaScript to render static text and images. Switching to Astro stripped the runtime payload to zero.
When we initially spun up the Just Write Apps site, Next.js was the default reflex. It’s the industry standard for React apps, so we ran create-next-app and moved on.
A week later, inspecting the network tab felt ridiculous.
We were shipping a massive client-side React runtime, hydration scripts, and JSON page-props payloads just to display static manifesto paragraphs and app specs. There were no client interactive state machines or dynamic user sessions on the marketing site—just pure editorial content.
Why Astro Won Out
1. Zero JavaScript by Default
Astro renders every page to clean, static HTML and CSS at build time. There is no React hydration overhead, no layout shifts while JavaScript bootstraps, and no framework runtime shipped to the browser:
# Build output comparison
Next.js client bundle: ~85KB - 120KB gzip JS per route
Astro client bundle: 0KB JS (Pure static HTML/CSS)2. Type-Safe Content Collections with Zod
Managing devlogs in raw markdown files usually degrades into broken frontmatter dates and missing image tags. Astro’s src/content/config.ts validates schemas at build time:
export const blogSchema = z.object({
title: z.string(),
description: z.string(),
pubDate: z.coerce.date(),
author: z.string().default('bforce'),
tags: z.array(z.string()).default([]),
image: z.object({
url: z.string().url(),
credit: z.string().optional(),
creditLink: z.string().url().optional(),
}).optional(),
});If a draft is missing a description or has an invalid date, astro check fails the build immediately in CI before deployment.
3. Instant SST AWS Deployment
Our site deploys via SST to AWS CloudFront and S3 as immutable static assets. Fast builds, zero container servers to babysit, and sub-10ms global edge delivery.