htmx vs React: When Hypermedia Beats JavaScript Frameworks

React once dominated frontend development, but in 2026, developers are rethinking its role. Enter htmx - a lightweight, server-driven library that simplifies building interactive apps without heavy JavaScript frameworks. Here's why htmx is gaining traction:

• React’s Complexity: React requires extensive tooling (state management, build pipelines, etc.) and often leads to bloated codebases.
• htmx's Simplicity: At just 14KB, htmx uses HTML attributes to handle interactions, cutting frontend code by 40–60% in CRUD-heavy apps.
• Performance: htmx eliminates hydration delays and reduces JavaScript shipped by up to 96%, resulting in faster load times.
• Developer Sentiment: While React usage remains high (83.6%), satisfaction is declining due to its complexity. htmx offers a simpler alternative.

Quick Comparison:

Key Takeaway: React excels in complex, real-time, or offline-first apps. htmx is ideal for CRUD apps, admin panels, and content-heavy sites. Many teams combine both for a balanced approach, using React for interactive widgets and htmx for simpler tasks.

React vs HTMX: Why we chose HTMX?

sbb-itb-bfaad5b

Why htmx is Growing in Popularity in 2026

The web development world in 2026 is undergoing what some call a Hypermedia Renaissance - a noticeable move away from the default reliance on single-page applications (SPAs). These days, building with modern React often involves six layers of tooling - meta-frameworks, state management, data fetching tools, build pipelines, TypeScript, and testing infrastructure - before developers even get to the actual business logic. This stack of tools can lead to unnecessary complexity, where the tools themselves overshadow the core purpose of the application.

htmx offers an alternative by simplifying this process. Its design focuses on Locality of Behavior (LoB), meaning you can understand what a piece of code does just by looking at it. Instead of spreading logic across various scripts, htmx embeds it directly into HTML attributes like hx-get and hx-target. This makes it clear how an element behaves when interacted with, without the need to dig through multiple files. Additionally, htmx revives the HATEOAS (Hypermedia As The Engine Of Application State) principle of REST, where servers send HTML fragments that define what users can see and do.

"htmx is more than a library; it is a correction to the excesses of the JavaScript age." - Prabhat Pushp, Developer

The rise of edge computing has also played a big role in htmx's growing adoption. By 2026, advancements in edge runtimes have nearly eliminated the latency concerns of server round-trips. This makes server-driven updates feel almost as fast as managing local state, challenging the long-held belief that SPAs are inherently "faster" for users.

For teams transitioning CRUD-heavy applications to htmx, the benefits are clear. Many report a 40-60% reduction in frontend code, and tests show a 60× decrease in JavaScript shipped compared to React-based implementations.

Perhaps the most telling sign of htmx's rise is the change in developer sentiment. While satisfaction with traditional JavaScript frameworks is waning - thanks to bloated node_modules directories and increasing complexity - htmx offers a refreshing simplicity. Its "script tag renaissance" allows developers to build interactive apps without any complex build tools. All it takes is including the lightweight 14KB library and adding attributes to your HTML.

What is htmx and How Does it Work?

Let's dive into how htmx, a lightweight 14KB JavaScript library, operates and why it's gaining traction among developers.

At its core, htmx enhances HTML by introducing attributes that let you trigger HTTP requests and update specific parts of a webpage - all without writing custom JavaScript. Instead of manually coding event handlers or fetch calls, you simply add these attributes to your HTML. When the server processes the request, it sends back an HTML fragment that htmx seamlessly integrates into the page.

This approach challenges the traditional single-page application (SPA) model. As HK Lee, a solo web developer, describes:

"htmx treats the browser as a document viewer that can swap parts of the document. Your server returns HTML fragments. The client has no application state, no routing logic, no build step."

HTML Attributes and AJAX

htmx makes use of declarative HTML attributes to define interactions. These attributes make it easy to specify what happens when users interact with elements on your page. Some of the most commonly used attributes include:

• hx-get or hx-post: Define the URL for the request.
• hx-trigger: Specify the event that triggers the request (e.g., click, change).
• hx-target: Indicate the element to update with the server's response.
• hx-swap: Control how the new HTML is inserted into the DOM.

Here’s a quick example:

<button hx-post="/api/items" hx-target="#item-list" hx-swap="beforeend">
  Add Item
</button>

When clicked, this button sends a POST request to /api/items. The server responds with an HTML snippet, which htmx inserts at the end of the #item-list element. This approach, known as Locality of Behavior, keeps all logic tied to the relevant HTML element, making your code easier to read and maintain.

Want to debounce inputs or show a loading spinner? Add modifiers like hx-trigger="keyup changed delay:500ms" or use hx-indicator for a visual cue during the request-response cycle. Even complex interactions can be managed declaratively, with the server driving all UI updates.

Server-Driven UI Updates

htmx shifts rendering responsibilities back to the server, eliminating the need for client-side state management. For instance, when a user deletes an item from a list, the server processes the action and sends back updated HTML, which htmx inserts into the page. This means you don’t need tools like Redux or React hooks to track the UI state - the server maintains the single source of truth.

Quantum Tricks, a full-stack developer, highlights this simplicity:

"HTMX brings back something we forgot: HTML can handle interactions. You do not need JavaScript to make things dynamic. You need better HTML."

For even more flexibility, htmx supports features like Out-of-Band swaps with the hx-swap-oob="true" attribute. This allows you to update multiple parts of the page in one response. For example, you could refresh a cart count in the header while adding an item to a list. Additionally, htmx includes an HX-Request: true header with every request, so the backend can differentiate between full-page loads and partial updates.

React in 2026: Server Components and Added Complexity

By 2026, React has evolved into a framework that divides its component tree into two distinct layers: a server layer for handling data-heavy logic and a client layer for interactive elements, made possible through the "use client" directive. React Server Components (RSC), which were once experimental, have become a standard feature, debuting as the default in React 19 and Next.js 16.

This architectural shift addresses long-standing issues like hydration fatigue - where browsers struggle to process large amounts of JavaScript before a page becomes interactive. RSC allows developers to create async components that can directly query databases, removing the need for separate data-fetching hooks or API routes. The result? JavaScript bundle sizes for content-heavy sites can shrink by 40–70%, and cutting out around 200 KB of JavaScript can improve time-to-interactive by 1–3 seconds on mid-range mobile devices.

As Robin Solanki explains, "Server Components are HTML generators. Client Components are JavaScript widgets". This distinction forces developers to carefully decide which components belong on the server versus the client, while also navigating strict serialization rules that prevent functions or class instances from crossing these boundaries. To manage this complexity, a comprehensive stack is essential. This typically includes a meta-framework like Next.js or Remix, state management tools such as Zustand or Jotai, data-fetching solutions like TanStack Query, modern build tools like Vite or Turbopack, and validation libraries such as Zod.

However, this added sophistication has come at a cost. According to the 2025 State of JS survey (published in February 2026), React still boasts an 83.6% usage rate, but its satisfaction score has dropped due to the ecosystem's growing complexity. For example, a simple "Hello World" app built in Next.js 16 ships with about 184 KB of JavaScript, compared to just 14 KB for htmx or 0 KB for pure server-rendered HTML. The tradeoff is clear: while React can deliver performance improvements, these gains often come with significant architectural overhead - a cost that only makes sense for applications requiring React’s advanced features.

This complexity has nudged the industry toward hybrid models, favoring server-driven approaches where possible and relying on client-driven logic only when necessary. React’s evolution highlights the importance of letting the server drive application flow, but it does so with added layers of complexity - unlike htmx, which takes a simpler, more declarative HTML-based approach.

Architecture Comparison: SPA vs Hypermedia-Driven Applications

React operates as a browser-based runtime for managing both state and UI, while htmx treats the browser more like a viewer for server-rendered HTML. This fundamental distinction shapes how each framework handles data flow and rendering.

"React treats the browser as an application runtime... htmx treats the browser as a document viewer that can swap parts of the document."
– HK Lee, Solo Web Developer

In a React single-page application (SPA), which relies on client-side rendering, the server provides JSON data through API endpoints. The client processes this data, converts it into UI components, and manages the application's state using tools like hooks or libraries such as Zustand. On the other hand, htmx takes a simpler approach by sending pre-rendered HTML fragments directly from the server, eliminating the need for client-side parsing or state management.

Switching from React to htmx can lead to dramatic reductions in complexity. Teams have reported cutting their codebase by 67% and reducing JavaScript dependencies by a staggering 96%. Performance gains are also notable: in a 2025 test, an htmx-powered dashboard loaded in just 412ms, compared to 2,847ms for its React SPA counterpart.

The choice between these two approaches often boils down to a tradeoff between control and simplicity. React provides detailed control over every interaction, but this comes at the cost of managing a complex stack involving meta-frameworks, state management, data fetching tools, build pipelines, TypeScript, and more. In contrast, htmx offers a streamlined experience with no build steps, no transpilation, and no client-side state management. However, it is inherently tied to what the server can deliver over HTTP, which limits its flexibility compared to React. These distinctions make htmx a better fit for projects prioritizing simplicity, while React is ideal for applications requiring fine-grained control.

Comparison Table: SPA vs Hypermedia Architectures

Here’s a side-by-side look at the key differences between the two architectures:

Code Comparison: Building the Same Feature in htmx vs React

Let’s dive into a practical example: creating a dynamic "resend OTP" button with a countdown timer. Back in March 2026, the Ark Protocol engineering team tackled this task using both React and htmx. The results? It took three days to build in React, compared to just three hours with htmx. Why the massive time difference? The React version faced challenges like debugging state synchronization issues and dealing with "stop-start progress." Meanwhile, htmx handled the timer state on the server, sending back simple HTML updates, making the process far smoother and more efficient.

Code Volume and Simplicity: htmx vs React

When it comes to the amount of code required, htmx is far more concise. Here’s how the two compare:

• htmx: A mere 5–8 lines of HTML attributes like hx-post and hx-target are enough to define the entire action directly on the button.
• React: You’ll need over 25 lines of JavaScript/JSX before even structuring the component. This includes setting up useState for the countdown, useEffect for the timer logic, and adding error handling for failed requests.

Larger Applications: The Trend Continues

This efficiency isn’t limited to small features. Consider Quantum Tricks’ experience in November 2025. They rebuilt a production admin dashboard originally written in React. The numbers tell the story:

• React Version: 3,200 lines of code with an 847KB bundle.
• htmx Version: Just 890 lines of code (a 72% reduction) with a 14KB bundle.

The htmx version didn’t just shrink the codebase - it also slashed load times from 2.4 seconds to an impressive 180ms.

"The htmx version is 8 lines of HTML attributes. The React version is 25+ lines of JavaScript before you even touch the JSX. And the React version introduces additional failure modes, such as stale cache and race conditions." – HK Lee, Solo Web Developer

Real-World Simplicity: Another Example

For something as straightforward as displaying a user profile, the difference is equally striking:

• React: Requires around 18 lines of code, including three state variables (user, loading, error) and a useEffect hook to fetch data.
• htmx: Achieves the same result in just 2 lines using hx-get and hx-trigger="load" to fetch an HTML fragment from the server.

These examples highlight how htmx, with its server-driven UI approach, reduces complexity by offloading much of the client-side logic. The result? Cleaner code, fewer bugs, and faster development.

Performance: Bundle Size, Time-to-Interactive, and Server Load

When it comes to performance, htmx leaves React far behind. With a bundle size of just 14 KB (5 KB gzipped) compared to React's hefty 847 KB (278 KB gzipped), the difference is staggering. And it’s not just size - htmx loads in a mere 412ms, while React takes a sluggish 2,847ms. That’s 60 times less JavaScript and a much faster load time for htmx implementations.

On a throttled 3G network, the gap widens even more. htmx achieves a Lighthouse score of 94, whereas React struggles at 34. This makes htmx an attractive choice for CRUD apps and admin panels, where performance and simplicity often outweigh the need for complex frameworks.

The secret to htmx's speed lies in its architecture. Unlike React, which relies on a hydration phase - where the browser must download, parse, and execute a large JavaScript bundle - htmx skips this entirely. Instead, it sends pre-rendered HTML fragments that directly update the DOM, delivering near-instant interactivity.

"The HTMX version loaded seven times faster than React. It shipped 60 times less JavaScript. It took one-third the code." – Quantum Tricks, Full-stack Developer

However, htmx's speed doesn’t come without tradeoffs. By shifting the workload to the server, it increases server-side processing, as the server now renders HTML fragments instead of just serializing JSON. Yet, with modern edge computing and advances in streaming HTML (as of 2026), this tradeoff has become more manageable. HTML fragments also cache exceptionally well on CDNs, unlike dynamic JSON responses, which are harder to cache effectively.

Here’s a quick breakdown of the key performance metrics:

Comparison Table: Performance Metrics

Developer Experience: Learning Curve, Tooling, and Debugging

As highlighted in earlier sections, htmx’s simplicity makes it much easier for developers to work with. Backend developers, and even those just starting out, can pick it up quickly since it builds on their existing knowledge of HTML.

React, however, presents a much steeper learning curve. Before you can even begin creating components, you’ll need to grasp concepts like the Virtual DOM, JSX syntax, state management, props, hooks, re-rendering cycles, and the overall Single Page Application (SPA) architecture. This requires adopting a completely new way of thinking about web development.

"htmx offers a smooth learning curve. Developers already familiar with traditional web development can master it in a few days, while newcomers can start using it from day zero." – Antonello Zanini, Software Engineer

The contrast extends to tooling as well. React often requires a heavy stack of additional tools - meta-frameworks, state management libraries, data-fetching solutions, and build pipelines. Its ecosystem is massive, with over 6,000 libraries available on npm. In comparison, htmx operates with a much smaller ecosystem of around 35 packages.

Debugging is another area where these two tools diverge. htmx keeps things simple with its request-response logic. You can troubleshoot issues using your browser’s DevTools to inspect network requests or by checking server logs. React, on the other hand, requires specialized tools like React Developer Tools to navigate its complex component hierarchies, state management flows, and reactivity patterns. While React does offer advanced debugging features like time-travel debugging, htmx’s straightforward approach means you’ll encounter fewer layers to sift through when tracking down issues. However, htmx does lack some modern developer experience features, such as syntax highlighting, linting, and static analysis for its custom attributes.

Here’s a quick comparison of these aspects:

Comparison Table: Developer Experience

When htmx Wins: CRUD Apps, Admin Panels, and Content Sites

htmx shines in projects centered around Create, Read, Update, Delete (CRUD) operations. Think of data tables with filters, settings forms, multi-step wizards, or content management systems - these are the bread and butter of htmx. As Quantum Tricks puts it:

"Most web apps are just CRUD. Create, read, update, delete. You click a button. Something happens on the server. The page updates."

This straightforward approach is why htmx is such a strong fit for many CRUD-based applications.

Another area where htmx stands out is admin panels and internal tools. Developers often share how quickly they can put together interactive admin interfaces with htmx - what might take a week with React can often be done in just a day. A 2025 case study highlighted how rebuilding an admin dashboard with htmx not only cut down the codebase but also significantly improved load times compared to React.

Content-heavy websites - like blogs, e-commerce product pages, and documentation sites - also gain a lot from htmx. Its server-side rendering keeps content easily indexable by search engines, without needing complex SSR setups. At the same time, it allows for interactive features like live search, "add to cart" buttons, or infinite scrolling, all achieved using simple HTML attributes. Performance metrics discussed earlier in the Performance section further highlight htmx's effectiveness in these scenarios.

One of htmx's biggest advantages lies in its architecture. Because the server already handles database state, validation, and business logic, htmx can directly return updated HTML fragments. This eliminates the need for extra layers like useState hooks, Redux stores, or data-fetching libraries that often complicate simple CRUD workflows. The result? Less code complexity and smoother user interactions.

For applications focused on standard CRUD operations - such as internal tools and content sites - developers who switch to htmx report reducing frontend code by 40–60%. Features that used to take days to build are now completed in hours. Plus, for backend developers working with Python, Go, or Ruby, htmx removes the need to dive into the intricacies of JavaScript frameworks. Instead, they can create dynamic, interactive UIs using the server-side languages they’re already comfortable with.

When React Wins: Complex SPAs, Real-Time UIs, and Mobile Apps

While htmx shines in handling CRUD operations, React takes the lead in scenarios that demand complex client-side state management. React operates as a full application runtime in the browser, managing state locally. This makes it the go-to choice for applications with intricate data relationships, where tools like its Hooks, Context API, and libraries such as Redux thrive. This capability is especially critical for apps where even the slightest delay in local interactivity can be a dealbreaker.

React truly excels in real-time collaborative tools. Platforms like Notion or Google Docs, which rely on managing complex local states down to microsecond precision, benefit immensely from React. Every keystroke, cursor movement, and selection happens on the client side to eliminate latency. As HK Lee, a solo web developer, puts it:

"A 200ms round-trip to the server for every keystroke isn't viable. This is client-side application territory".

React's virtual DOM allows for efficient batch updates and integrates seamlessly with protocols like CRDTs (Conflict-free Replicated Data Types). In contrast, htmx's request-response model isn't built to handle such demands.

Another key differentiator is offline-first applications. Apps like field service tools, mobile note-taking platforms, or point-of-sale systems often need to function without a server connection. With htmx, every interaction depends on a live server connection - no server, no functionality. React, however, uses service workers and IndexedDB to enable offline operations, offering features like optimistic UI updates, where user actions are immediately reflected even before server confirmation. This makes React a clear choice for apps requiring both high interactivity and resilience in offline conditions.

React also holds a strong advantage in mobile development through React Native, which allows developers to build cross-platform apps for iOS and Android with a native look and feel. Features like complex gestures, drag-and-drop functionality, and animation-heavy interfaces demand frame-rate responsiveness that React handles through local state management. On slower networks, htmx interactions can experience up to 500ms of lag due to server round-trips, while React ensures near-instant responsiveness, crucial for high-frequency interactions.

For applications requiring rich interactivity, real-time updates, or seamless cross-platform deployment, React remains an essential tool despite the added complexity of its component-based architecture and build tools.

The Middle Ground: Using htmx and React Together

Sometimes, finding a balance between server-rendered simplicity and client-side interactivity is the way to go. The "Islands of Interactivity" approach is a great example of this. With this method, you let htmx handle the page structure, navigation, and basic CRUD tasks, while React takes charge of more complex, interactive widgets like rich text editors or real-time charts. This hybrid setup gives you the best of both worlds.

Take GitHub as an example - they use server-rendered HTML for most content but rely on targeted JavaScript for intricate components like code editors and file trees. Similarly, you could use htmx to manage product listings and checkout flows, reserving React for something like an interactive product configurator. One SaaS company reported impressive results after adopting this approach: a 67% smaller codebase and a 96% drop in JavaScript dependencies by shifting simpler sections to htmx while keeping React for advanced editing features.

To make this work smoothly, you'll need to integrate carefully. For example:

• Use the data-hx-preserve attribute on htmx-managed sections to prevent React from overwriting them.
• Trigger htmx processing with window.htmx.process(document.querySelector('#htmx-container')) inside a useEffect hook.
• Avoid event conflicts by using e.stopPropagation() and e.preventDefault().

If you're looking to simplify an existing React app, a gradual migration can make the process easier. The "Strangler Fig" strategy is a smart way to do this - start by replacing less interactive pages, like settings forms or data tables, with htmx while keeping React for highly dynamic features. This step-by-step approach can significantly reduce your app's bundle size - from a typical 150–400 KB React bundle to htmx's lightweight 14 KB, plus smaller React widgets. And the best part? You don’t need to rewrite everything from scratch.

"The best architecture is the one that matches your problem. A Notion clone needs React. An admin dashboard needs htmx. A SaaS product might need both." – HK Lee, Solo Web Developer

Conclusion: Choosing the Right Tool for Your Application

Pick the tool that aligns with your project's specific needs. For admin dashboards, internal tools, or content-heavy websites where SEO and fast initial load times are priorities, htmx’s 14 KB size and server-driven approach can be a great fit. Teams working with backend languages like Go, Python, or Ruby can create dynamic UIs without diving into complex JavaScript build tools or state management libraries.

On the other hand, React shines in applications requiring highly interactive experiences. Whether it’s rich text editors, real-time collaboration platforms, or offline-first apps, React's client-side runtime is ideal for building desktop-like functionality (think Figma-style tools) or handling intricate local state management.

Many teams find success with a hybrid approach. Instead of choosing one over the other, the Islands of Interactivity pattern combines the strengths of both. Use htmx for simpler tasks like navigation, forms, and data tables, while reserving React for more complex, interactive widgets. This approach takes advantage of htmx’s lightweight nature while strategically deploying React where it’s most effective, reinforcing earlier performance insights.

Balancing server-driven simplicity with client-side complexity requires careful consideration of your team’s expertise and project demands. If your team includes frontend specialists and your project needs offline capabilities or real-time collaboration, React’s added complexity becomes worthwhile.

Ultimately, what matters most is the user experience.

"Users do not care what framework you used. They care if the page loads fast and the buttons work." – Quantum Tricks, Full-stack Developer

FAQs

How do I decide if my app should use htmx or React?

When deciding between htmx and React, the best choice depends on the type of application you're building and its specific requirements.

• htmx is a great fit for content-driven apps like blogs, admin panels, or server-rendered sites. Its lightweight nature (just about 14KB) and focus on server-driven updates make it ideal for CRUD-based applications with minimal client-side complexity.
• On the other hand, React shines in more complex scenarios. If you're building highly interactive single-page applications (SPAs) or tools with real-time features, React’s robust ecosystem supports advanced client-side interactivity. However, it does come with larger bundles (around 200KB) and added development complexity.

Ultimately, the right choice comes down to your app’s goals, level of interactivity, and how much complexity you're ready to manage.

What backend changes do I need to make to use htmx well?

To get the most out of htmx, your backend needs to return HTML fragments rather than full pages. This means setting up endpoints that handle various HTTP methods like GET and POST, then responding with partial HTML designed to update specific parts of your user interface.

This approach fits neatly with the principles of hypermedia-driven development. Plus, it helps keep client-side JavaScript simple and lightweight. Make sure your backend efficiently manages state and processes requests to deliver these fragments without hiccups.

Can I mix htmx and React on the same page safely?

Yes, it's entirely possible to use htmx and React on the same page, allowing you to take advantage of what each does best. For instance, you can rely on htmx for straightforward, server-driven tasks like CRUD operations, while reserving React for more intricate client-side interactions.

That said, combining them requires careful planning to avoid potential issues, particularly around event handling and DOM updates. When done right, this approach can enhance performance and make development smoother.

Related Blog Posts

• React 19: Everything you need to know in one place
• Next.js vs Nuxt.js: What's Best?
• Next JS GraphQL Integration Basics
• React SSR with Next.js: Step-by-Step