The Pendulum Came Back
Single-page apps owned the last decade. By 2026, the smartest teams are quietly going the other way.
Not abandoning React. Not declaring war on JavaScript. Just shipping less of it.
HTMX picked up roughly 16,800 GitHub stars in 2024 alone. Hotwire is the default for every new Rails 8 application. React Server Components and the Next.js App Router are the React team’s way of admitting that streaming HTML from a server is a good idea.
The conversation in 2026 isn’t “SPA vs. server-rendered.” It’s “how much client-side JavaScript do you actually need?”
For most B2B applications, the answer is: a lot less than you’ve been shipping.
Two Tools, Same Idea
HTMX is a roughly 16KB JavaScript library, minified and gzipped. Add an attribute to a button, and the button makes an HTTP request. The server returns HTML, and HTMX swaps it into the page.
That’s the whole pitch. No build step. No npm dependency tree. No virtual DOM.
Hotwire is the same idea, packaged for Rails (and now Phoenix, Django, and Laravel via ports). Turbo handles page navigation and streaming partial updates. Stimulus adds tiny pinches of JavaScript when you need them.
Both let you write a server-rendered application that feels like an SPA. The difference: you’re shipping kilobytes, not megabytes.
A standard React + Next.js + state-library bundle ships roughly 250-500KB of JavaScript before your code runs. Hotwire ships about 30KB. HTMX ships about 16KB.
That gap matters more than it used to. INP (Interaction to Next Paint) replaced FID as a Core Web ranking signal in March 2024, and Google now scores pages on it. Every script that blocks the main thread costs you ranking and conversions.
What’s Actually New in 2026
HTMX 2.0 (released June 2024) dropped IE11 support, removed the legacy attribute aliases, and split WebSocket and SSE into extensions. Smaller core. Cleaner mental model.
The 2.0.x point releases since (current: 2.0.10, April 2026) tightened swap semantics and shipped a public htmx.swap() API for cleaner partial replacement. HTMX 4.0 is in beta with a Summer 2026 target, swapping XHR for fetch() under the hood.
Turbo 8 (released early 2024) shipped page-level morphing. Instead of swapping full DOM trees, Turbo now diffs and patches in place. Forms keep their focus. Scroll positions stay where they were. The user feels nothing.
Combined with Turbo Streams over WebSockets, you get optimistic updates and real-time collaboration patterns without writing a single line of client state-management code.
Phoenix LiveView, Laravel Livewire, Django Unicorn. Same architecture, different ecosystems. The pattern won.
Where Server-Rendered Wins
CRUD apps, which is most apps
B2B SaaS is forms, tables, dashboards, and reports. A user clicks a row. They see a detail page. They edit a field. They save.
You don’t need 400KB of client-side state for this. You need fast page loads and snappy transitions.
Hotwire and HTMX deliver both with one developer instead of three. We covered the framework side of this in why we still choose Rails for B2B SaaS, but the same logic applies to Django, Phoenix, or Laravel.
Internal tools and admin panels
Basecamp. HEY’s webmail. GitHub’s logged-in navigation runs on Turbo Drive over a Rails backend. 37signals’ new ONCE products ship with the same stack. All serving large professional user bases every day on a fraction of the JavaScript a comparable React app would need.
Internal users don’t care if your dashboard loads in 600ms or 200ms. They care that it works, looks consistent, and doesn’t need a separate frontend team to maintain.
A real example. We had a manufacturing client running their admin on a Next.js + GraphQL stack their previous agency built. Three engineers, fourteen months of work, still buggy. The “admin” was three screens: customers, orders, products.
We rebuilt it in Rails with Hotwire. Six weeks. One developer. Same screens, faster, fewer bugs. The client kept the React stack for their public storefront. Different problem, different tool.
Compliance-heavy products
If you’re shipping software into healthcare, finance, or government, every line of client-side JavaScript is potential audit liability. Each third-party npm dependency is a supply-chain risk.
A Rails 8 app with importmap-rails ships zero npm packages: Turbo and Stimulus arrive as ESM modules, served straight from the asset pipeline. A fresh create-next-app resolves to over a thousand transitive dependencies before you’ve written any code. That difference shows up in pen tests and SBOM reports.
Public-sector teams have started reaching for HTMX for exactly this reason. No build pipeline. No Webpack lockfile to audit. An app you can read top to bottom in an afternoon.
Anywhere you don’t have a frontend team
Most companies don’t have a dedicated frontend team. They have a small group of full-stack developers who’d rather not think about webpack configuration.
For them, Hotwire and HTMX collapse the stack. Same language, framework, and deployment. No coordination tax, no “the API team needs to add this field before we can build the screen.” One developer ships features end to end.
Where SPAs Still Win
Honest take: SPAs still win sometimes. We’ve shipped React, Vue, and Svelte applications when they were the right call. Here’s when.
Real-time collaboration. Figma, Miro, Notion, Linear. These applications have to manage thousands of objects in client memory, sync state across users in milliseconds, and stay responsive during heavy edits. Server-rendered models break down here.
Canvas and creative tools. Drawing apps, video editors, level editors, anything with drag-and-drop on a 2D plane. These are inherently client-heavy. Don’t fight it.
Offline-first. PWAs that need to work without a network connection have to put state in the browser. Server-rendered approaches assume a server is reachable.
Single-purpose, deeply interactive products. A spreadsheet. A code editor. A project planner with a Gantt chart. The interactivity is the product.
The honest test: is the interactivity essential to what users do, or is it polish on top of CRUD? If it’s polish, server-rendered with Hotwire or HTMX gets you 95% of the experience for 5% of the complexity.
React Quietly Came to the Same Conclusion
The most interesting part of the React ecosystem in 2024-2025: React itself moved server-side.
React Server Components run on the server, render to HTML, and stream incrementally to the browser. The Next.js App Router defaults to server components. Client components are now opt-in.
Read that again. The framework that defined the SPA era has client components as opt-in.
Why? Because the React team noticed what Rails developers have known for two decades: most of an application doesn’t need to be interactive. Render it on the server, ship the HTML, hydrate the parts that actually move.
Same architecture as Hotwire. Same architecture as HTMX. Same architecture as Phoenix LiveView. The labels are different. The pattern is identical.
Inertia.js: The Pragmatic Middle
For our clients who genuinely need a richer frontend (think dashboards with complex filters, drag-and-drop kanban boards, embedded data viz), we reach for Inertia.js.
Inertia lets you write Rails or Laravel controllers that return data. The data renders through a React or Vue component. No separate API server. No CORS. No duplicated routing. No GraphQL schema to maintain.
Inertia 2.0 (March 2025) closed most of the remaining gap with a hand-rolled SPA. Deferred props, prefetching on hover, polling, and a WhenVisible component. You get React’s component model with the productivity of a server-rendered framework, for the small set of apps that actually need both.
What We Ship for Clients in 2026
Default: Rails 8 + Hotwire + PostgreSQL on a single Hetzner server. Total infrastructure cost: 40-80 EUR/month. Time to a working MVP: 6-10 weeks.
When the application warrants it: Rails or Laravel + Inertia + React. Adds a couple of weeks of frontend setup. Pays for itself the moment you need a complex screen.
When HTMX is the better fit: Python or Go backends where the team doesn’t want a JavaScript build pipeline. Government work. Audit-heavy environments. Internal tools the same team has to maintain for years.
When pure SPA is the right call: real-time collaboration, canvas tools, offline-first products. Then we ship React or SvelteKit, hosted appropriately.
The decision isn’t “which is best.” It’s “which fits this application.” Most of the time, in 2026, that answer is “less JavaScript than you’d think.”
If you want a deeper read on how we make these calls across a stack, our tech stack decision framework walks through the trade-offs with worked examples.
Building a B2B product and wondering whether you actually need a full SPA? Let’s talk through it. We’ll look at your requirements honestly and tell you when server-rendered makes more sense than another React build.
