The Web Tech Stack We're Actually Betting On in 2026

Every few months, a new framework becomes the consensus "right" choice for web development. Next.js, Astro, Remix, SvelteKit — the options multiply faster than the genuine insights into when each one is appropriate.

We maintain a clear standard stack at TiltStack. This post explains what it is, why we chose it, and where we'd deviate from it — including the situations where we'd recommend something entirely different for your project.

This is an opinionated post, not a balanced overview. If you want balanced, read the framework docs. This is what we've learned after building real production sites for real businesses.

Our Standard Stack and Why

For most small-to-midsize business websites: Eleventy (11ty) + SASS + esbuild + Firebase Hosting

We've standardized on this stack because it consistently produces the best outcome on the metrics we can actually measure:

• Lighthouse mobile performance: 91–97 across our builds, consistently
• LCP under 1.5 seconds on standard broadband mobile connections
• CLS of 0.0–0.02 — essentially zero layout shift

The reason is architectural. Eleventy generates static HTML at build time. The browser receives pre-rendered HTML and renders it immediately — no JavaScript framework hydration, no server-side computation on request, no database lookup. It's the fastest possible web delivery model for content that doesn't change per-user.

Our JavaScript payload for a typical business site: 8–40KB total, deferred. Our CSS payload per page: 18–28KB, with non-critical sheets loaded async. These numbers are difficult to achieve with a framework-based stack without heroic optimization effort.

For comparison: a typical Next.js page (even with aggressive optimization) ships at minimum 70–130KB of framework JavaScript before your application code. For a marketing site or content site, that JavaScript does almost nothing the user needs — it's hydration overhead for a server-rendered page that could have been static HTML.

When We'd Use Eleventy

• Marketing / lead generation sites for local or regional businesses
• Content-heavy sites (blogs, knowledge bases, documentation)
• Portfolio sites and agency sites
• Any site where the primary goal is organic search ranking and fast load times
• Sites where the owner wants to manage content via Markdown (no CMS login required)

Eleventy handles all of these better than any other option we've used.

When We'd Actually Use Next.js

Next.js is a genuinely excellent framework. We use it for specific use cases where its complexity is justified:

Authenticated user experiences. If your site has logged-in users with personalized data — a dashboard, a member portal, a SaaS product — you need client-side routing and state management. Static HTML doesn't work here. Next.js or React with a proper backend is appropriate.

E-commerce with complex product/inventory logic. A Shopify integration or custom cart system with real-time inventory, personalized pricing, or complex checkout flows legitimately benefits from React/Next.js.

High-frequency content that must be on-demand. If your site serves content that changes per-request based on user identity or live data, static pre-rendering doesn't work. Next.js's hybrid rendering (SSR + ISR) handles this well.

The mistake we see agencies make is defaulting to Next.js for everything — including blogs and marketing sites where a static generator is objectively better. The result is a slower site with more operational complexity for no benefit.

What We're Watching But Not Betting On Yet

Astro: Technically impressive — its partial hydration model ("islands architecture") is conceptually correct for content sites with some interactive components. We're watching it but haven't standardized on it because Eleventy is simpler, faster to configure, and the ecosystem is more mature for our use cases. Astro 4.x is the first version where we'd seriously evaluate it for a new project.

Bun: JavaScript runtime innovation is real. Bun's speed improvements over Node.js are measurable. We haven't migrated our build pipeline to Bun because the risk/reward isn't there yet — esbuild running on Node.js is already fast enough that Bun's improvement is imperceptible in our build times. Revisiting in 2026 when the ecosystem stabilizes.

Edge-first deployment (Cloudflare Workers, Deno Deploy): Interesting architecture for applications that need true global low-latency responses for authenticated or dynamic content. For static content delivery, Firebase Hosting's CDN already gives us global edge performance. For dynamic backends, Firebase Cloud Functions cold starts are acceptable for our SMB use cases. Edge-first adds complexity without clear benefit at our current scale.

WebAssembly for business sites: Not relevant to our current project types. WASM is genuinely transformative for specific high-performance use cases (gaming, video processing, scientific computing in the browser). For a law firm website or a custom web app, it introduces complexity with no benefit.

The Framework Churn Problem

One underappreciated cost of framework-heavy stacks: the maintenance burden over 3–5 years.

A React site built in 2020 on Create React App is already a legacy project — CRA is deprecated, the migration to Vite or Next.js is non-trivial, and the dependency graph has layers of version conflicts to untangle.

A well-structured Eleventy + SASS site built in 2021 is still running fine, still passes Core Web Vitals, and requires minimal maintenance. The tech is boring — and boring is a feature in production infrastructure.

We build sites clients can actually maintain for years without constant framework upgrades. That's a deliberate product decision.

Specific Technology Decisions That Matter

esbuild over webpack. esbuild bundles JavaScript 10–100x faster than webpack and produces smaller output. We use it for all client-side JS bundling. For our use case (multiple small JS files, not a large SPA), webpack's plugin ecosystem offers no benefit we need.

SASS over Tailwind. Tailwind is a legitimate choice for component-heavy React/Next.js applications where you're working in a design system with many recurring patterns. For our custom builds — where every section is designed custom and the CSS is specific to that section — Tailwind adds cognitive overhead without simplifying the output. SASS with CSS custom properties gives us everything we need with less noise in the HTML.

Firebase Hosting over Vercel/Netlify. Vercel and Netlify are excellent platforms with strong DX. We use Firebase because: it integrates natively with Firebase Cloud Functions (serverless backend) and Firebase Realtime Database (for form submissions, chatbot state), it's Google infrastructure with a global CDN, and it gives us a single provider for frontend hosting + backend + database + auth. When everything is in one Firebase project, operational complexity is significantly lower than managing separate providers.

Self-hosted WOFF2 fonts over Google Fonts. Google Fonts is convenient but: it's an external DNS lookup (performance hit), it adds a privacy-relevant third-party request, and Chrome's privacy changes have reduced font caching benefits anyway. Self-hosting the WOFF2 files with proper font-display: swap and <link rel="preload"> gives us identical visual result with meaningfully better performance and no third-party dependency.

The Question We Actually Ask Before Choosing a Stack

Not "what's the most exciting technology right now?" but: "what will be easiest for this client's site to maintain, perform, and rank in 3 years?"

That question consistently leads us to the simpler, more boring choice. Eleventy over Next.js for a marketing site. SASS over Tailwind for a custom design build. Firebase over a multi-provider setup. Vanilla JS over Alpine.js for a navigation toggle.

When the exciting choice and the boring choice produce the same outcome, we take the exciting one. In practice, for business websites, the boring choice almost always produces the better outcome on the metrics that matter.

FAQs

Q1: Should I use Eleventy or Next.js for my business website?
A: If your website is primarily marketing/content with no authenticated user sessions or real-time personalized data: Eleventy. If you have logged-in users, a dashboard, or product/inventory that varies per-user: Next.js. The primary decision factor is whether your content is static (the same for every visitor) or dynamic (personalized per-session). Most small business marketing sites are static.

Q2: Is WordPress still a viable option in 2025?
A: For very specific use cases — particularly large content operations that require non-technical content teams to manage a large volume of pages — WordPress is still viable. For most small business sites in 2025, its performance overhead, plugin maintenance burden, and security exposure make it a poor default choice. We don't build on WordPress for performance-critical or SEO-competitive sites.

Q3: What's the actual performance difference between Eleventy and Next.js for a simple business site?
A: A comparable business site in Next.js (even with static generation enabled) ships approximately 70–150KB of hydration JavaScript that an Eleventy build doesn't. On mobile 3G simulation, that's a measurable difference in both LCP and INP. Our Eleventy builds consistently score 91–97 on PageSpeed mobile; Next.js sites for equivalent use cases typically score 75–88 with standard optimization, and require active work to get higher.

Q4: What CMS do you use for content management on Eleventy sites?
A: We use Markdown files as the CMS. Blog posts are .md files with YAML frontmatter. This is lower friction than it sounds — Markdown is human-readable, version-controlled in Git, and requires zero CMS login or SaaS dependency. For clients who need a graphical interface, we've integrated with Decap CMS (formerly Netlify CMS) on select projects, which provides a Git-backed editorial interface without a database.

Q5: How do you handle form submissions on a static Eleventy site?
A: All form submissions are handled by Firebase Cloud Functions — a serverless Node.js function that receives the POST request, validates it, and routes to email (via SendGrid or Nodemailer) and/or Firebase Realtime Database for storage. This gives us server-side validation, rate limiting, and spam protection while keeping the frontend completely static.