Modern web stack 2026: Astro, Tailwind v4, Cloudflare Workers

The web stack we use in 2026 is deliberate, opinionated, and has earned its way into our default after a lot of trial and error. This is a tour for fellow builders — and for clients curious about what their site or app is actually built on.

The five pieces

For a typical small business marketing site or web application:

1. Astro for the page layer and routing.
2. Tailwind CSS v4 for styling.
3. React (when needed) for interactive islands.
4. Cloudflare Pages + Workers for hosting and compute.
5. Cloudflare D1, R2, KV for data, storage, and caching.

For a project that doesn’t need a backend (a marketing site, a portfolio, a content site like this blog), you can stop at Cloudflare Pages and have a complete, free-tier-friendly stack.

Why Astro

The pitch for Astro is simple: it ships zero JavaScript by default. Pages render as static HTML. JavaScript only loads where you explicitly opt in to interactive components.

For a marketing site this is transformative. Compare a typical Next.js marketing site (200–500KB of JavaScript on first load) to an Astro equivalent (0–30KB). Lighthouse scores go from “needs work” to “perfect” without any performance tuning. Time to interactive collapses.

Astro also has excellent content collections — strongly-typed Markdown/MDX with frontmatter validation via Zod. The blog posts you’re reading right now are typed Markdown files validated at build time, with TypeScript-aware autocomplete in editors. Content moves fast when it’s just files.

For application UI within an Astro site, you use “islands” — components rendered in React (or Vue, Svelte, Solid) only where interactivity is needed. The static parts stay zero-JS. The interactive parts get exactly the JavaScript they require.

Why Tailwind v4

Tailwind v4 fixed the three biggest complaints about v3:

1. Speed. The Oxide engine compiles 10–100x faster than v3. Watch mode actually feels instant.
2. CSS-first configuration. Theme tokens live in CSS (@theme { --color-canvas: #0f0f12 }) instead of a tailwind.config.js. This is more natural and works better with CSS-in-CSS workflows.
3. Native CSS layers. The cascade is predictable and well-defined.

The case for Tailwind itself is well-trodden. For a 2-person studio shipping consistent design across client projects, having a shared utility vocabulary is dramatically faster than starting from scratch each time. We have a consistent set of opinionated utilities, colors, and spacing across every project we ship.

The case against Tailwind (“ugly markup”) is real but overrated. For maintenance, having styles colocated with markup beats hunting through a separate stylesheet. For consistency, having a shared spacing/color system beats designer-prefers-pixel-perfect freedom.

Why React (and when not)

For interactive application UI — forms, dashboards, complex state — React is still the default we reach for. The ecosystem is enormous, the talent pool is wide, and the documentation is excellent. Client handoff is easier when the chosen framework is the one any competent web developer can pick up.

The catch: React is the wrong tool for non-interactive content. A blog post that’s just text shouldn’t be a React component tree. Astro handles that case correctly by default, and we use React only for the parts that need it.

For projects in 2026 we’d happily use Vue or Svelte instead of React if the client’s existing team is fluent in either. Both work as Astro islands. None of them is dramatically better than the others for typical SMB application work — pick the one your team can maintain.

Why Cloudflare

We wrote a longer post specifically about Cloudflare, but the short version:

• Pricing scales gently. No surprise bills.
• Edge-by-default. Low latency without configuration.
• Integrated suite. Compute, DB, storage, CDN, queue, cron, AI all on one platform.
• Free tier is genuinely useful. Marketing sites run on free tier indefinitely.

For client work this matters: we hand off systems that cost predictable money to operate. Small businesses do not want to monitor cloud bills.

What this stack looks like in practice

A typical project structure:

src/
├── content/        # Markdown content (blog posts, case studies)
├── layouts/        # Page layouts (Layout.astro)
├── pages/          # Routes — file-based routing
├── components/     # Astro/React components
├── styles/         # Tailwind + custom CSS
├── scripts/        # Vanilla JS / TS utilities
├── content.config.ts  # Zod schemas for content collections
└── env.d.ts        # Type declarations

For a project with a backend, add:

worker/             # Cloudflare Worker code
├── api/            # API route handlers
├── db/             # D1 migrations + queries
└── lib/            # Shared logic
wrangler.jsonc      # Cloudflare config

The whole thing deploys to Cloudflare Pages with wrangler pages deploy dist or via a GitHub integration. Total deploy time: 15–60 seconds.

A representative cost breakdown

For a typical marketing site:

• Domain: ~$12/year
• Hosting (Cloudflare Pages): $0 on free tier (unlimited bandwidth and requests for most SMB traffic)
• Analytics (Cloudflare Web Analytics): $0
• Email forwarding (Cloudflare): $0
• Total monthly: under $2/month amortized

For a small business application with auth + database + AI:

• Cloudflare Workers Paid: $5/month base
• D1 + R2 + KV: $5–$30/month at SMB scale
• Auth0 / Clerk: $25–$150/month
• OpenAI / Anthropic API: $20–$300/month depending on volume
• Email (Resend/Postmark): $20/month
• Sentry: $26/month
• Total: typically $100–$500/month

That’s dramatically less than equivalent stacks on AWS or with managed SaaS components.

What we’d add or swap

A few things on our radar for 2026:

• Auth.js / better-auth as a Clerk/Auth0 alternative for clients who want auth fully in-house.
• Bun runtime for build tooling — already significantly faster than Node for our use cases.
• Drizzle ORM for D1 — type-safe queries with minimal overhead, better than raw SQL string building for non-trivial apps.

We’d swap away from this stack only for specific reasons: heavy real-time video, dedicated ML infrastructure, federal compliance requirements, or a client mandate to use a specific incompatible stack. For 95% of small business web work, this is what we reach for.

If you’re starting a new project and want a second opinion on the stack, we’re happy to talk it through. The right stack depends on the project; we don’t try to sell ours when something else fits better.