Compare Astro
Stacks vs Astro

Astro is right about content sites. Stacks is for the day it stops being one.

For a marketing site, a blog, or documentation, Astro is hard to beat: almost no client JavaScript, content collections with type-checked frontmatter, and islands only where you need interactivity. Stacks is not trying to win that comparison. It is the answer when the site grows accounts, a dashboard, and a queue.

See what ships All comparisons

What Astro is.

In its own terms, not ours.

Astro ships zero JavaScript by default, lets you drop React, Vue, or Svelte components in as islands, and has the most pleasant content pipeline in the ecosystem. Content collections, image optimisation, and the integrations catalogue make a docs or marketing site fast to build and fast to load. Server output and actions have extended it toward applications, but content remains its centre of gravity.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick Astro for

  • Content sites, decisively

    Content collections, MDX, and the image pipeline are better than what Stacks offers for a pure content site, and the output is lighter.

  • Bring any component library

    React, Vue, Svelte, and Solid islands in one project is a genuinely useful escape hatch.

  • Static output

    A fully static build deployed to any CDN has an operational simplicity nothing here beats.

  • Integrations catalogue

    Sitemaps, RSS, analytics, and search are usually one integration away.

Pick Stacks for

  • It is an application framework

    Accounts, roles, billing, background work, and an admin dashboard are the things Astro is not trying to be.

  • A CMS you own

    Posts, authors, categories, and comments are models with an editing surface, rather than markdown a developer commits.

  • Dynamic and static together

    Marketing pages, a docs site, a blog, and an authenticated product live in one project and one deploy.

  • Infrastructure and mail

    DNS, certificates, CDN, and transactional mail come from the same config the app reads.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks Astro
Primary use Applications that also have content Content sites that sometimes have an island
Default output Server-rendered pages Static HTML with optional server output
Content authoring CMS models plus markdown Content collections in the repository
Client JavaScript Signals where needed None unless you add an island
Data layer First-party ORM Choose your own
Auth Included Bring your own or a service
Background work Included Not applicable
Admin surface Generated from models A git-based or hosted CMS

If you did move.

What ports cleanly, what does not, and where to start.

Content moves cleanly

Markdown in content/ works much the same way, and frontmatter maps onto model attributes when you want an editing surface.

Astro pages become STX views

The template shapes are similar enough that pages port faster than React or Vue components do.

Consider keeping both

An Astro marketing site in front of a Stacks application is a sensible arrangement, and the shared palette is the only coupling.

The verdict.

Both answers are real. Most teams already know which paragraph is theirs.

Choose Astro when

The project is content, its success is measured in page speed and publishing convenience, and it will not grow accounts or background work.

Choose Stacks when

There is a product behind the marketing site, or there will be, and you would rather not run two stacks to serve one brand.

The frameworks that usually come up in the same conversation.

Stacks vs Next.js

The React meta-framework. Stacks answers the backend questions Next.js deliberately leaves open.

Stacks vs RedwoodJS

The closest thing to a full-stack JavaScript framework before this one. Different bets, same goal.

Stacks vs SvelteKit

Small bundles and a lovely reactivity model. Stacks adds everything behind the load function.