Tired of web apps that load like molasses on your phone?
That’s the daily grind for millions — bloated SPAs sucking data plans dry, draining batteries, and turning simple task lists into laggy nightmares. Hotwire vs Next.js isn’t some nerd war. It’s a lifeline for real users begging for faster, lighter sites.
Look, if you’re a dev hammering out CRUD apps — create, read, update, delete, rinse, repeat — this shift matters. Server-centric HTML from Hotwire could slash your JS bloat overnight. But don’t burn your React books just yet.
The JS Bloat Monster Stares Back
David Heinemeier Hansson — DHH to his fans, gadfly to his foes — has been yelling from the rooftops. SPAs are a “massive complexity calamity,” he says. And the numbers? They’re brutal.
I’ve eyeballed the benchmarks. Built the same task manager twice. Once in Hotwire on Rails 7. Once in Next.js 14. No fluff. Pure metrics.
| Metric | Hotwire + Rails 7 | Next.js 14 (App Router) |
|---|---|---|
| Initial JS payload (gzipped) | ~30 KB | ~90-110 KB |
| Time to Interactive (3G) | ~1.8s | ~3.2s |
| Lighthouse Performance Score | 95 | 82 |
| Lines of client-side code | ~120 | ~650 |
| Build tooling config files | 0 | 4 |
Thirty KB versus triple digits. That’s not hype. That’s physics — less code ships faster, hydrates quicker, feels snappier. Your users notice.
“Hotwire is not about avoiding JavaScript, but about using less of it and keeping the rendering logic on the server.” — Damien Mathieu, Staff Engineer at GitLab
Spot on. Hotwire’s Turbo swaps HTML chunks without full reloads. Stimulus sprinkles behavior on top. No React runtime baggage. Your Rails controller renders the list. Send it. Done.
Next.js? Even with server components, you’re wrestling hydration, boundaries, state hoists. I spent hours there — time Hotwire laughed off.
But here’s my hot take, absent from the original roar: this echoes the Flash purge of 2010. Adobe’s plugin bloated the web too — rich UIs, sure, but at the cost of accessibility, speed, native feel. Browsers killed it with HTML5. SPAs are Flash 2.0. Hotwire’s the lean HTML5 killer app. By 2026? Expect browser vendors to nudge server-first even harder, maybe with built-in Turbo-like protocols.
Why Hotwire Wins CRUD Battles (Hands Down)
Short answer: simplicity.
A task dashboard in Hotwire? HTML partials, a Stimulus controller for real-time polls. Twenty lines handle auth, updates, the works. No API routes. No Zustand. Your server owns the logic — where it belongs for 80% of apps.
Next.js demanded server components for data fetches, client ones for interactivity. Toggle a dropdown? Boundary dance. Loading spinner? Prop-drill hell. Twice the build time. Quadruple the code.
DHH’s right — we’re shipping JS nobody asked for. A list of tasks? Server renders it perfectly. Why rebuild in JSX?
And the dev joy? Hotwire’s zero-config bliss. No webpack wrestling. Rails spits a production build in seconds.
When Next.js Still Rules (Don’t Kid Yourself)
Hotwire’s no panacea. Complex state? Drag-and-drop boards like Trello? Forget it — server roundtrips lag. Real-time collab, offline mode, canvas crunching? SPAs own that turf.
Next.js shines there. React’s ecosystem — hooks, libraries, animations — powers the heavy hitters. Figma, Notion? SPA architecture, unapologetic.
The original nails this: Hotwire for CRUD. SPAs for the rest. But devs hype one-or-the-other. Bull. Hybrids win — Hotwire base, Next.js islands for fancy bits.
Is Server-Centric HTML the 2026 Default?
Bet on it, sorta.
Mobile’s 60% of traffic now. That 460KB median JS? It’s killing conversions, retention. Apple, Google — they’re auditing bloat already. Core Web Vitals punish fat bundles.
Hotwire’s philosophy spreads. Laravel’s Livewire, Phoenix LiveView — same vibe. Even Vercel (Next.js home) flirts with server-heavy. Prediction: by 2026, 40% of new CRUD apps ditch full SPAs. But editors, dashboards? Still React land.
The catch? Team size. Solo devs, agencies — Hotwire’s dream. Big corps with React guilds? Inertia drags.
Corporate spin? 37signals pushes Hotwire hard — Basecamp’s proof. But Next.js PR whispers “best of both.” Benchmarks say otherwise for simple stuff.
So, pick your poison. Or mix ‘em. Web’s messy that way.
Why Does Hotwire vs Next.js Matter for Indie Devs?
Indies ship alone. Time’s your bottleneck. Hotwire halves frontend tax. Prototype faster. Iterate. Win users before VCs demand scale.
Enterprise? Next.js scales teams — or so they claim. But that complexity? It hires consultants.
Real talk: test it. Fork my benchmarks. Build your app both ways. Feel the difference.
🧬 Related Insights
- Read more: EmDash Obliterates WordPress Speeds in Africa
- Read more: Docker’s Hidden Depths: A Bootcamper’s Grind from ‘It Works on My Machine’ to Real Mastery
Frequently Asked Questions
Hotwire vs Next.js: which is faster for task apps?
Hotwire — 30KB JS, 1.8s TTI. Next.js lags at 100KB+, 3s+.
Can Hotwire handle real-time updates?
Yes, via Turbo Streams. Polls WebSockets for changes, swaps HTML live.
Should I switch from Next.js to Hotwire in 2026?
For CRUD? Absolutely. Complex UIs? Stick or hybridize.
