HTMX 2.0: The Anti-Framework Winning Developers Over

HTMX 2.0 launched November 6, 2025, bringing a morph plugin for intelligent DOM updates, View Transitions API integration for smooth animations, and enhanced WebSocket support. The 14 KB library is part of a growing “HTML-over-the-wire” movement where developers are pushing back against React and Next.js complexity. For many web apps, HTMX proves you don’t need a JavaScript framework. You need HTML that doesn’t suck.

What HTMX 2.0 Brings to the Table

The morph plugin is the game changer here. It provides intelligent DOM diffing without virtual DOM overhead, preserving focus, scroll position, and form state during updates. Syntax is simple: hx-swap="morph". Use case? Live dashboards and real-time feeds that update without jarring UI refreshes.

View Transitions API integration means native browser animations between states without requiring a CSS framework. It works in Chrome 111+ and Safari 18+, delivering SPA-like smoothness without SPA complexity. The syntax is equally straightforward: hx-swap="innerHTML transition:true".

Performance improvements include 15% faster attribute parsing, better caching, and reduced memory footprint. HTMX stays at roughly 14 KB while React’s base bundle clocks in at over 100 KB before you write a single line of application code.

The Philosophy: Simplicity Over Complexity

Carson Gross, HTMX’s creator, has a clear stance: “Most web apps are CRUD. CRUD doesn’t need client-side routing, state management, or hydration. Server-rendered HTML with AJAX is sufficient and simpler.”

The React ecosystem solves problems, but it creates them too. Build tools like Webpack, Vite, and Turbopack churn constantly. Bundle sizes balloon from 50 KB to 800 KB (one developer’s real experience). State management libraries multiply: Redux, Zustand, Jotai, MobX. Backend developers get forced to learn an entire JavaScript ecosystem just to add interactivity to a form.

HTMX takes a different approach. It enhances HTML with attributes rather than replacing it. Server-driven UI updates work with any backend: Django, Rails, Laravel, Go, Rust, whatever you’re already using. No build step. No npm dependency hell.

Here’s what that looks like:

<button hx-get="/api/users" hx-target="#user-list" hx-swap="morph">
  Load Users
</button>
<div id="user-list"></div>

The server responds with an HTML fragment. HTMX swaps it in. Done. No React components, no useState, no useEffect, no mental overhead.

When to Use HTMX vs React

HTMX excels for content-heavy sites like blogs, documentation, and e-commerce catalogs. It works well for backend-first teams who have deep expertise in Django, Rails, or Laravel but don’t want to maintain a separate JavaScript codebase. It’s ideal when SEO is critical and you need fast initial loads with minimal JavaScript footprint. It’s perfect for rapid prototyping and MVPs.

React still wins for highly interactive UIs like design tools and rich text editors. Offline-first apps need robust client-side state that HTMX can’t provide. Real-time collaboration (think Google Docs) requires client-side conflict resolution that server-round-trips can’t handle efficiently. Complex mobile experiences benefit from React Native’s ecosystem.

The nuanced truth, as one Reddit developer put it: “HTMX vs React is a false choice. Use both for different parts.”

Real-world adoption proves this isn’t vaporware. GitHub uses HTMX-style approaches for code search filters. Basecamp’s HEY email client runs on Hotwire Turbo, which shares HTMX’s philosophy. Gumroad uses it for product pages and checkout. Startups deploy it for admin panels and internal tools where development velocity matters more than framework religion.

The Bigger Picture: Framework Fatigue

HTMX is one player in a broader HTML-over-the-wire movement. Hotwire Turbo brings similar ideas to Rails through convention. Phoenix LiveView uses WebSockets to achieve server-driven UIs in Elixir. Unpoly focuses on progressive enhancement.

Why now? Framework fatigue is real. Developers are burned out on React and Next.js complexity. Build tool churn causes constant breaking changes. Performance pressure from Core Web Vitals and Lighthouse scores makes every kilobyte count. There’s a renewed appreciation for server-rendered simplicity.

Reality check: React still dominates with over 70% of the SPA market. HTMX sits in a niche estimated at 5-10% adoption. But that niche is growing. Backend teams, performance-critical applications, and progressive enhancement projects are finding HTMX fits their needs better than heavyweight frameworks.

The Controversial Take

“SPAs are solving problems most web apps don’t have.” That’s Carson Gross again, and he’s not wrong. Eighty percent of web applications are CRUD operations: create, read, update, delete. CRUD doesn’t need client-side routing, state management, or hydration. React and Next.js over-engineer solutions for problems that don’t exist in most codebases.

React developers will counter: “But components! Reusability! TypeScript!” Fair points. But HTMX asks a better question: Do you need that complexity for your specific problem? Or are you using React because it’s the default, because that’s what everyone else does?

HTMX 2.0 proves you don’t need to choose between interactivity and simplicity. You need to choose the right tool for your problem. For content-heavy sites, backend-first teams, and developers tired of framework churn, that tool might not be React. It might be HTML that actually works the way you need it to.