Astro vs TanStack Start: when I reach for each

People ask what stack I build on, and the honest answer is “it depends on whether the page needs to think.” That’s not a dodge — it’s the whole decision tree. Almost every site I ship splits into two kinds of pages, and each kind has a clear best tool.

The split: does this page need to think per request?

A page that shows the same thing to everyone — a homepage, a service description, a blog post, a service-area landing page — doesn’t need a server running when someone visits. It can be built once, turned into plain HTML, and served from the edge as a static file. That’s an Astro page. This site you’re reading right now is Astro, prerendered to static HTML and served from Cloudflare’s edge.

A page that has to do something different depending on who’s asking — a checkout, a signed-in dashboard, a contract someone has to view and sign, a form that talks to a database — needs code running per request. That’s a TanStack Start page, server-rendered on a Cloudflare Worker.

That single question — does this page need to think per request? — sorts about 95% of the work.

Why Astro for the static side

For marketing and content pages, Astro’s advantage is that it ships almost no JavaScript by default. A static service page has no client-side framework runtime to download, parse, and execute before it’s interactive, because there’s nothing interactive to hydrate. The browser gets HTML and CSS and renders it. That’s why static-first pages tend to score well on Core Web Vitals without much fighting — the cheapest JavaScript is the JavaScript you never sent.

Astro also has a clean content-collection system for blog posts and structured content, which is exactly what you want for a site that’s mostly pages-of-words. The post you’re reading is an MDX file in a content collection. No CMS round-trip, no database query — it’s compiled to HTML at build time.

The tradeoff: a static page can’t react to the visitor. If you need that, you reach for the other tool.

Why TanStack Start for the dynamic side

When a page needs auth, a database, or per-request logic, I use TanStack Start running as a server on a Cloudflare Worker. It server-renders the page with the right data already filled in, so the visitor isn’t staring at a loading spinner while the browser fetches what the server already knew. Sign-in flows, dashboards, checkout, document signing — anything gated or personalized — lives here.

The reason this works cleanly is that both halves deploy to the same platform: Cloudflare Workers at the edge. The static Astro pages and the dynamic TanStack pages can sit behind the same domain, share the same API, and stay physically close to the database. A static marketing page can link straight into a dynamic checkout without the visitor ever leaving the site or noticing the handoff.

The decision tree, condensed

Here’s the actual flow I run when I’m scoping a new page:

1. Does it show the same thing to everyone, every time? → Astro, prerendered static. Fastest possible load, near-zero JavaScript.
2. Does it need a small piece of interactivity (a form, a calculator, a toggle) but the page itself is otherwise static? → Astro with a small client-side island for just that piece. Don’t hydrate the whole page to make one button work.
3. Does it need auth, a database read/write, or per-request logic? → TanStack Start, server-rendered on a Worker.
4. Either way: deploy to Cloudflare’s edge so it’s fast everywhere and the dynamic pages stay close to the data.

Why not just pick one and use it for everything?

You can, and plenty of people do. Using a dynamic framework for static pages works — it’s just slower and heavier than it needs to be, because you’re running a server (and shipping a client runtime) to render something that never changes. Using a purely static tool for dynamic pages doesn’t really work at all; the moment you need auth or live data, you’re bolting a backend on anyway.

Matching the tool to the page is the cheapest performance and reliability win available, and it costs nothing at runtime. The marketing pages stay feather-light. The app pages get a real server when they need one. And because it’s all Cloudflare Workers underneath, it’s one deploy target, one domain, one mental model.

If you want to see the static side in action, the free tools here are Astro pages with small interactive islands — exactly pattern #2 above. The audit form is a tiny client-side island on an otherwise static page, talking to the same edge API the dynamic apps use. That’s the whole stack, on display.