Islands architecture: most pages ship zero JavaScript, only the interactive islands hydrate on demand.
Server-side data fetching conventions are less mature than Next.js. Works fine for static sites, more thinking required for full SSR apps.
- ✓You're building a content site, blog, documentation, or marketing site where SEO matters.
- ✓You're integrating a headless CMS (Sanity, Contentful, Storyblok) and want minutes-to-bootstrap.
- ✓You're deploying to a CDN or edge network and want static-output simplicity.
- ✗You're building a full-app SaaS where 80%+ of pages are interactive React surfaces.
- ✗You need server-rendered React with deep ecosystem dependencies. Next.js is more mature here.
Overview
Astro is the web framework that powers Vibetoolstack. Every page on this site (47-program listicle, tool reviews, blog posts, /tools and /compare landing pages) ships as a static HTML build from an Astro source tree, deployed to Cloudflare Workers via a GitHub Action cron.
Astro's positioning is content-first: pages render to static HTML by default, JavaScript only hydrates the interactive islands you opt into. The result is sub-second time-to-interactive on content sites without the React-app penalty.
Pros & Cons
Pros
• Zero-JS-by-default produces genuinely fast page loads. Vibetoolstack pages routinely score 100/100 on Lighthouse mobile
• Component model (.astro files) is closer to HTML than React JSX. Lower barrier for content editors and designers
• First-class integrations with major headless CMS (Sanity, Contentful, Storyblok), minutes, not hours, to bootstrap
• Built-in image optimization, sitemap, RSS, MDX, Markdown. Modern publishing primitives baked in
• Strong community + free + MIT licensed. No vendor risk
Cons
• SSR setup is more involved than Next.js for full-app use cases
• Major-version migrations (3 → 4 → 5 → 6) have required code changes. Not pure-additive
• Smaller ecosystem of UI component libraries vs. Next.js or Nuxt
• Server-side data fetching patterns less convention-driven than Next.js or Remix
My Experience
VTS runs Astro 6.1
Vibetoolstack uses Astro 6.1.5 with @sanity/astro 3.3 for the CMS integration, astro-portabletext 0.13 for Sanity's Portable Text rendering, astro-pagefind 1.8 for client-side search, Tailwind 4.2 via the Vite plugin, and @astrojs/sitemap 3.7 for the sitemap generator. Roughly 200+ pages render from this stack per build, deploy time around 90 seconds.
What we use it for
Static-output (output: "static"). Every blog post, tool review, comparison page, and listicle is pre-rendered at build time. The drip-publish system relies on this: a GitHub Action cron triggers a rebuild every 30 minutes between 06:00 and 22:30 UTC, picks up newly-due Sanity docs, and ships them to Cloudflare Pages.
Custom mark components (ExternalLink.astro, SlugHeading.astro) for Portable Text rendering. The auto-affiliate-rel system relies on this pattern: ExternalLink hooks the body markDef, checks hostname against AFFILIATE_DOMAINS, adds rel="sponsored nofollow noopener" automatically.
What broke (so you don't have to)
Astro's SSR mode for preview routes needed an adapter swap (@astrojs/cloudflare) since we deploy static elsewhere. The preview/[slug].astro route runs SSR-only while the rest stays static. Worth flagging if you're building Sanity-preview into a static Astro site.
Tailwind 4 + Astro Vite integration occasionally drops base styles on first build of a fresh dev server. Re-run dev fixes it. Frustrating but recoverable.
Pagefind indexing happens post-build, which means the build step runs longer than a pure Astro site. Worth the trade for client-side search that costs zero per query.
What we'd do again
Default to islands architecture, not full React-tree hydration. Most pages on Vibetoolstack have zero JavaScript in production builds, and that shows in Core Web Vitals and Google's perception of the site's quality.
Build Sanity-Astro components as a thin pass-through layer rather than re-deriving content. Astro's component model is great at "render this Sanity Portable Text with these mark overrides"; less great at "fetch and transform large datasets on every request".
Best Use Cases
Content-heavy sites and publishers
Astro's sweet spot. Blogs, documentation, marketing sites, listicles, comparison sites. Anywhere the content-to-interactivity ratio is high, Astro outperforms React-app-first frameworks on time-to-interactive and SEO scores.
Headless CMS frontends
Integrations exist for Sanity, Contentful, Storyblok, Strapi, Hygraph. Most are one-line additions to astro.config.mjs. The Portable Text or rich-text rendering is the only piece you actually write yourself, and it's straightforward.
Static deployment to edge networks
Astro's default output is HTML files that any CDN serves. Cloudflare Pages, Vercel, Netlify, S3+CloudFront, Fastly. The deploy-to-edge story for static-output Astro is the simplest in 2026.
Selective interactive islands
When you DO need React or Vue components, Astro lets you embed them as islands with client:load, client:idle, or client:visible directives. Lets you start static-first and progressively add interactivity only where it earns its hydration cost.