Modern web development has become synonymous with JavaScript frameworks. React, Vue, Angular, Svelte — each brings its own component model, state management patterns, build tools, and learning curve. For many applications, this complexity is justified. But there is a growing movement that asks a provocative question: what if HTML itself could do more?
HTMX is the embodiment of that question. At just 14 kilobytes minified and gzipped, HTMX extends HTML with attributes that allow any element to issue HTTP requests and update the DOM with the server's response — no JavaScript required. At StrikingWeb, we have started using HTMX for specific project types, and the results have been eye-opening.
The Hypermedia-Driven Approach
To understand HTMX, you need to understand the hypermedia philosophy that underpins it. In the early days of the web, the browser was a hypermedia client. You clicked a link, the browser made an HTTP request, and the server returned a complete HTML page. Every interaction followed this simple, elegant pattern.
Then Ajax arrived, and we started returning JSON from the server and rendering it on the client with JavaScript. This was powerful but introduced enormous complexity: now the client needed its own state management, routing, templating, and rendering logic. The server became a JSON API, and the browser became an application platform.
HTMX proposes a middle path: keep the server as the source of truth for HTML rendering, but allow more elements and events to trigger HTTP requests, and allow the server to return HTML fragments that update specific parts of the page. The browser remains a hypermedia client, just a more capable one.
How HTMX Works
HTMX works through HTML attributes. No JSX, no virtual DOM, no state management libraries. Here are the core attributes:
Making Requests
hx-get, hx-post, hx-put, hx-patch, and hx-delete allow any HTML element to make HTTP requests. A button that loads content when clicked looks like this:
<button hx-get="/api/users" hx-target="#user-list">Load Users</button>
When clicked, HTMX makes a GET request to /api/users, and the HTML returned by the server replaces the content of the element with ID user-list.
Targeting and Swapping
hx-target specifies which element to update with the response. hx-swap controls how the content is placed — innerHTML, outerHTML, beforeend, afterbegin, and other options give you fine-grained control over DOM updates.
Triggers
hx-trigger specifies what event triggers the request. The default is natural — clicks for buttons, submits for forms — but you can trigger on any event, including custom events, with modifiers like throttling and debouncing:
<input hx-get="/search" hx-trigger="keyup changed delay:300ms" hx-target="#results" name="q">
This creates a live search input that fires a request 300 milliseconds after the user stops typing, replacing the contents of the #results element with the server's response.
Real-World Patterns
Infinite Scroll
With traditional JavaScript, infinite scroll requires intersection observers, state management for pagination, and careful rendering logic. With HTMX, it is a single attribute:
<div hx-get="/items?page=2" hx-trigger="revealed" hx-swap="afterend">Loading...</div>
When this element enters the viewport, HTMX loads the next page and appends it after the element. The server returns more items with an updated trigger element for the next page. No JavaScript whatsoever.
Inline Editing
Click-to-edit UI patterns that would require state management and form handling in React can be built with HTMX by having the server swap between display and edit modes, each represented as HTML fragments.
Real-Time Updates with SSE
HTMX supports Server-Sent Events out of the box through an extension. Your server pushes HTML fragments, and HTMX swaps them into the DOM automatically. This enables real-time dashboards and notifications without WebSocket client code.
When HTMX Shines
HTMX is not a universal replacement for React or Vue. It excels in specific contexts:
- Server-rendered applications: If your application is already server-rendered (Django, Rails, Laravel, Express with templates), HTMX adds interactivity without requiring a complete frontend rewrite
- Content-heavy sites: Blogs, documentation sites, e-commerce catalogs, and admin panels where the primary interaction is reading and navigating content
- Internal tools: Admin dashboards, CRUD interfaces, and data management tools where development speed matters more than pixel-perfect animations
- Small teams: Teams that do not have dedicated frontend engineers benefit from keeping the rendering logic on the server in a language they already know
- Progressive enhancement: Adding interactive features to existing server-rendered pages without rebuilding them as SPAs
When HTMX Is Not the Right Choice
We are honest with clients about HTMX's limitations:
- Rich client-side interactions: Drag-and-drop interfaces, real-time collaborative editing, complex data visualizations, and highly interactive maps are better served by client-side frameworks
- Offline-capable applications: HTMX requires a server connection for every interaction. PWAs and offline-first applications need client-side state management
- Complex state dependencies: When multiple UI elements depend on shared client-side state that changes frequently, React's component model and state management tools are genuinely superior
- Mobile apps: If you plan to share code between web and mobile (React Native), a React-based architecture makes more sense
"HTMX does not replace React any more than a bicycle replaces a car. They solve different problems at different scales, and the best engineering teams know when to use each."
The Performance Advantage
One of HTMX's most compelling arguments is performance. A typical React application ships hundreds of kilobytes (often megabytes) of JavaScript to the client. HTMX is 14 KB. The difference in initial load time, time-to-interactive, and performance on low-powered devices is dramatic.
Moreover, because HTMX applications render HTML on the server, the browser does not need to execute JavaScript to display content. This means faster First Contentful Paint, better Core Web Vitals scores, and a better experience for users on slow connections or older devices.
For SEO-sensitive applications, HTMX's server-rendered HTML is crawlable by default, without the hydration complexity and potential issues that come with SSR in React-based frameworks.
Pairing HTMX with Modern Backend Frameworks
HTMX is backend-agnostic, but some frameworks pair with it particularly well:
- Django + HTMX: The Python community has embraced HTMX enthusiastically. Libraries like django-htmx provide middleware and utilities that make the pairing seamless.
- Go + Templ + HTMX: Go's performance and the Templ templating library create a fast, type-safe stack that is excellent for internal tools.
- Laravel + HTMX: PHP's Laravel framework, already focused on server rendering, pairs naturally with HTMX for adding interactivity.
- Express/Fastify + HTMX: For Node.js teams, pairing HTMX with a server-side template engine like EJS or Handlebars offers a simpler alternative to full React applications.
Our Experience at StrikingWeb
We have used HTMX on three internal projects and two client projects in the past year. The results have been consistently positive for the right use cases:
- Development velocity was 30 to 40 percent faster compared to equivalent React implementations
- Bundle sizes were dramatically smaller, improving performance on mobile devices
- Backend developers could build interactive features without learning a frontend framework
- Maintenance burden was lower because there was no frontend build pipeline, no state management library, and no client-server data synchronization to debug
That said, we continue to use React and Next.js for applications that require rich client-side interactivity, complex state management, or code sharing with mobile applications. The key is choosing the right tool for the specific problem.
Getting Started
Adding HTMX to an existing server-rendered application takes minutes. Include the script tag, add a few attributes to your HTML elements, and create server endpoints that return HTML fragments. There is no build step, no configuration, and no new mental model to learn beyond HTTP and HTML.
If you are building a new project and wondering whether HTMX is the right approach, or if you have an existing application that could benefit from simpler interactivity, our team would be happy to evaluate your requirements and recommend the best path forward.