HTMX vs React: Why JavaScript Framework Fatigue Won

HTMX topped the 2024 JavaScript Rising Stars front-end frameworks category, adding 16,800 new GitHub stars to beat React by over 4,000. But this isn’t about HTMX winning a popularity contest. It’s about developers saying the JavaScript ecosystem went too far—and they’re choosing a 16KB library over React’s 200KB+ bundles because they’re exhausted. When 14% of JavaScript developers cite framework complexity and excessive choice as major pain points, HTMX’s rise isn’t surprising. It’s inevitable.

JavaScript Fatigue Is Real

JavaScript Fatigue isn’t a meme. JetBrains’ 2024 Developer Survey found 14% of JavaScript developers complain about framework complexity and “excessive choice.” The pain points are concrete: “choice overload” and “breaking changes” that force rewrites. One developer put it bluntly: “You might start in Angular, and after a year, all useful libraries require React—forcing you to rewrite your application.”

Starting a React project means configuring TypeScript, testing frameworks, formatters, linters, and bundlers before writing a single line of application code. The node_modules folder has become a punchline—notorious for size and redundancy. Stack Overflow surveys keep flagging the same issues: developer unhappiness, pressure from rapid change, and mental fatigue around tooling expectations. Developers aren’t just tired. They’re burned out.

This is the problem HTMX solves. Developers aren’t choosing it because it’s technically superior to React in all cases. They’re choosing it because React’s ecosystem complexity became unbearable for use cases that don’t need it.

HTMX vs React: The Philosophical Divide

HTMX takes a radically different approach: extend HTML instead of replacing it. Creator Carson Gross describes HTMX as “completing HTML as a hypermedia” by allowing any element to issue any HTTP request and update any part of the page. The server returns HTML fragments, not JSON. The application stays server-driven and hypermedia-based. It’s ~16KB vs React’s 200KB+ typical bundles.

Real-world ports from React to HTMX show 67% smaller codebases. Here’s why: HTMX eliminates the complexity. Consider infinite scroll. In HTMX, it’s four lines:

<div hx-get="/api/items?page=2"
     hx-trigger="revealed"
     hx-swap="afterend">
  Load More...
</div>

In React, the same feature requires useState, useEffect, fetch logic, scroll event listeners, Intersection Observer API, and component lifecycle management. That’s 50-100 lines for what HTMX handles in four. The ecosystem around HTMX is described as a “quiet town” vs React’s “bustling city”—liberating because you don’t have to make dozens of architectural decisions.

This isn’t about HTMX being a lighter React. It’s a completely different mental model. HTMX enhances HTML rather than replacing it with JSON APIs and client-side rendering. Understanding this shift is critical: it’s not “which is better” but “which philosophy fits your project.”

The SPA-By-Default Problem

Here’s the uncomfortable truth: the industry defaulted to SPAs for projects that don’t need them. Complex applications like Gmail warrant React’s sophistication. Simple content-driven sites, dashboards, and CRUD applications got React bundles anyway. The result? Developers noted “the effort to build SPAs is often bigger, often by an order of magnitude” for projects where traditional server-rendered approaches would suffice.

React became the hammer that made everything look like a nail. Most projects are screws that need a screwdriver. Excellent applications like Basecamp, GitHub, and Bitbucket prove you don’t need SPAs for outstanding user experience. Microsoft’s own guidance acknowledges that teams unfamiliar with JavaScript but familiar with server-side development will deliver traditional web apps more quickly than SPAs.

HTMX is ideal for content sites, dashboards, CRUD apps, and teams with strong backend expertise. React is ideal for complex SPAs with app-like interactivity, real-time collaboration, and offline-first requirements. The problem isn’t that React exists—it’s that it became the default when it should be the exception. HTMX’s rise forces the conversation: “Do you actually need a SPA?”

When HTMX Fails

HTMX is not a React replacement for all use cases, and that’s the point. HTMX fails for highly interactive applications like Figma or Notion, real-time collaborative editing, complex client-side state management, and offline-first apps. Every interaction requires a server round trip, creating network latency issues for operations that need instant feedback.

The limitations are real. There’s no React DevTools equivalent for debugging. The tooling ecosystem is small. Backend and frontend are tightly coupled because the server returns formatted HTML. HTMX advocates don’t claim it’s universal. But here’s the counter-argument: “simple use-cases” describe 90% of web projects. The industry assumed complexity was necessary when simplicity would work.

This balance matters for credibility. ByteIota’s stance isn’t “HTMX always beats React.” It’s “choose the right tool for the job.” When you acknowledge limitations honestly, the argument strengthens.

The Bigger Picture

HTMX’s 16,800 new stars in 2024 signal a broader trend: after years of “more JavaScript,” the pendulum is swinging toward “less JavaScript.” This includes the server-side rendering renaissance (Next.js, Remix), edge functions, and questioning the “SPA by default” assumption. Hacker News post “Please just try HTMX” generated 425 points and 361 comments—highly divisive, exactly as expected.

The 2024 JavaScript Rising Stars milestone reflects genuine frustration with framework churn, even accounting for HTMX’s viral marketing. Developers describe HTMX as “far more simple, productive, beneficial, and FUN for 90% of web dev use cases.” Whether that’s accurate or hyperbolic, the sentiment matters. HTMX may not “murder” React, but it forces the necessary conversation about when complexity is justified.

The industry is rethinking assumptions about web architecture. HTMX isn’t an anomaly—it’s part of a larger shift.

Key Takeaways

• JavaScript framework complexity is measurable: 14% of developers cite excessive choice and framework churn as major pain points, leading to documented burnout.
• HTMX’s philosophical difference matters: it completes HTML as hypermedia rather than replacing it with JSON APIs, resulting in 67% smaller codebases for many use cases.
• SPAs became the default when they should be the exception: most projects—content sites, dashboards, CRUD apps—don’t need React’s complexity.
• HTMX has real limitations for complex applications: highly interactive, real-time, or offline-first apps still need React’s capabilities. The point is choosing appropriately.
• The pendulum is swinging from “more JavaScript” to “less JavaScript”: HTMX’s rise is part of a broader industry shift questioning whether we overcomplicated web development.

React isn’t going anywhere, nor should it. Complex applications need sophisticated tools. But when did building a simple form require 50 dependencies and a build pipeline? HTMX’s success proves simpler approaches still work—and for most projects, they work better.