htmx: Building Modern Web Apps Without JavaScript Frameworks

The modern web development landscape is dominated by heavyweight JavaScript frameworks. React, Vue, Svelte, and their countless companions have reshaped how we build web applications, but they have also introduced layers of complexity that many projects simply do not need. Enter htmx — a small, declarative library that lets you build dynamic, interactive web applications using HTML attributes instead of writing JavaScript. In this guide, we will explore how htmx works, why it is gaining serious traction, and how you can use it to build modern web apps with dramatically less code.

What Is htmx and Why Does It Matter?

htmx is a lightweight JavaScript library (roughly 14KB minified and gzipped) that extends HTML with custom attributes for making AJAX requests, handling CSS transitions, working with WebSockets, and processing Server-Sent Events — all without writing a single line of JavaScript. Instead of sending JSON back and forth between client and server, htmx embraces hypermedia as the engine of application state (HATEOAS), returning HTML fragments from the server and swapping them directly into the DOM.

The core philosophy is simple: HTML was always meant to be the primary language of the web. htmx gives HTML the capabilities it should have had all along — the ability to issue any HTTP method, respond to any event, and update any part of the page. This approach eliminates the need for a separate front-end application layer, drastically reducing the amount of code you need to write and maintain.

If you have been evaluating different front-end approaches, our comparison of React vs Vue vs Svelte highlights how each framework handles reactivity and rendering. htmx offers a fundamentally different paradigm: instead of building a client-side application that consumes an API, you let the server render HTML and htmx handles the dynamic parts.

How htmx Works: Core Concepts

At its heart, htmx operates through a handful of HTML attributes. When a user interacts with an element that has htmx attributes, the library intercepts the event, makes an AJAX request to the server, and swaps the returned HTML into the specified target element. Here are the key attributes you need to know:

• hx-get, hx-post, hx-put, hx-patch, hx-delete — Issue HTTP requests of the corresponding method when the element is triggered.
• hx-trigger — Specify which event should trigger the request (click, submit, keyup, scroll, etc.).
• hx-target — Determine which DOM element should receive the response HTML.
• hx-swap — Control how the response is inserted: innerHTML, outerHTML, beforebegin, afterbegin, beforeend, afterend, delete, or none.
• hx-indicator — Show a loading indicator while the request is in flight.
• hx-push-url — Update the browser URL bar, enabling proper navigation history.
• hx-vals — Include additional values with the request.

These attributes cover the vast majority of interactive use cases. Combined with proper server-side rendering, they allow you to build applications that feel as responsive as SPA frameworks without the associated complexity. For a deeper understanding of the HTTP methods htmx uses, our guide on understanding REST APIs provides excellent background on how these methods work in practice.

Getting Started: Installation and Setup

One of htmx’s greatest strengths is its simplicity of setup. There is no build step, no node_modules folder, no webpack configuration. You add a single script tag and start using HTML attributes immediately:

<!-- Via CDN -->
<script src="https://unpkg.com/htmx.org@2.0.4"></script>

<!-- Or download and self-host -->
<script src="/js/htmx.min.js"></script>

That is it. No npm install, no framework CLI, no project scaffolding. This simplicity is a breath of fresh air for developers who have grown weary of complex toolchains. If you are building on solid HTML5 fundamentals, htmx will feel like a natural extension of what you already know.

Practical Example 1: Infinite Scroll with Server-Side Rendering

Infinite scroll is a common pattern in modern web applications. With traditional JavaScript frameworks, implementing it typically involves managing scroll events, tracking pagination state, fetching JSON data, and rendering components. With htmx, the entire pattern can be expressed in HTML attributes while the server handles all the logic.

Here is a complete implementation of infinite scroll using htmx with a Python Flask backend:

<!-- Frontend: articles.html -->
<div id="article-list">
  <div class="article-card">
    <h3>First Article Title</h3>
    <p>Article excerpt goes here...</p>
    <span class="meta">Published: March 2025</span>
  </div>

  <div class="article-card">
    <h3>Second Article Title</h3>
    <p>Another article excerpt...</p>
    <span class="meta">Published: February 2025</span>
  </div>

  <!-- Sentinel element: triggers loading when scrolled into view -->
  <div hx-get="/api/articles?page=2"
       hx-trigger="revealed"
       hx-swap="outerHTML"
       hx-indicator="#load-spinner">
    <div id="load-spinner" class="htmx-indicator">
      <span class="spinner"></span> Loading more articles...
    </div>
  </div>
</div>

<!-- Backend: Flask route (Python) -->
<!--
@app.route('/api/articles')
def get_articles():
    page = request.args.get('page', 1, type=int)
    per_page = 10
    offset = (page - 1) * per_page

    articles = db.execute(
        'SELECT title, excerpt, published_at FROM articles '
        'ORDER BY published_at DESC LIMIT ? OFFSET ?',
        (per_page, offset)
    ).fetchall()

    total = db.execute('SELECT COUNT(*) FROM articles').fetchone()[0]
    has_more = offset + per_page < total

    html = ''
    for article in articles:
        html += f'''
        <div class="article-card">
          <h3>{article["title"]}</h3>
          <p>{article["excerpt"]}</p>
          <span class="meta">Published: {article["published_at"]}</span>
        </div>
        '''

    if has_more:
        next_page = page + 1
        html += f'''
        <div hx-get="/api/articles?page={next_page}"
             hx-trigger="revealed"
             hx-swap="outerHTML"
             hx-indicator="#load-spinner-{next_page}">
          <div id="load-spinner-{next_page}" class="htmx-indicator">
            <span class="spinner"></span> Loading more articles...
          </div>
        </div>
        '''

    return html
-->

Notice what is happening here. The hx-trigger="revealed" attribute tells htmx to fire the request when the sentinel element scrolls into the viewport. The server responds with a batch of rendered HTML article cards and a new sentinel element for the next page. When there are no more articles, the server simply omits the sentinel, and the infinite scroll stops naturally. No client-side state management, no useEffect hooks, no intersection observer boilerplate — just HTML attributes and server-rendered responses.

Practical Example 2: Dynamic Form with Validation and Swap

Forms are the bread and butter of web applications. htmx makes dynamic form handling remarkably clean by allowing inline validation, partial updates, and seamless submission — all without page reloads. Here is a contact form with real-time email validation and a smooth submission flow:

<!-- Frontend: contact form with inline validation -->
<form hx-post="/contact/submit"
      hx-target="#form-container"
      hx-swap="outerHTML"
      hx-indicator="#submit-indicator"
      id="form-container">

  <div class="form-group">
    <label for="name">Full Name</label>
    <input type="text" id="name" name="name"
           required minlength="2"
           placeholder="Enter your name">
  </div>

  <div class="form-group">
    <label for="email">Email Address</label>
    <input type="email" id="email" name="email"
           hx-post="/contact/validate-email"
           hx-trigger="keyup changed delay:500ms"
           hx-target="#email-feedback"
           hx-swap="innerHTML"
           required
           placeholder="you@example.com">
    <span id="email-feedback"></span>
  </div>

  <div class="form-group">
    <label for="subject">Subject</label>
    <select id="subject" name="subject"
            hx-get="/contact/subject-fields"
            hx-trigger="change"
            hx-target="#dynamic-fields"
            hx-swap="innerHTML">
      <option value="">Select a subject...</option>
      <option value="general">General Inquiry</option>
      <option value="support">Technical Support</option>
      <option value="quote">Request a Quote</option>
    </select>
  </div>

  <div id="dynamic-fields">
    <!-- Additional fields loaded based on subject -->
  </div>

  <div class="form-group">
    <label for="message">Message</label>
    <textarea id="message" name="message"
              required minlength="10"
              rows="5"
              placeholder="Your message..."></textarea>
  </div>

  <button type="submit" class="btn-primary">
    Send Message
    <span id="submit-indicator" class="htmx-indicator">
      Sending...
    </span>
  </button>
</form>

<!-- Server response on successful submission replaces entire form -->
<!--
  Success response HTML:
  <div id="form-container" class="success-message">
    <h3>Thank you!</h3>
    <p>Your message has been sent. We will respond within 24 hours.</p>
    <button hx-get="/contact/form"
            hx-target="#form-container"
            hx-swap="outerHTML">
      Send another message
    </button>
  </div>

  Validation error response HTML (422 status):
  The server returns the entire form with error classes
  and messages appended to invalid fields.
-->

This form demonstrates several powerful htmx patterns working together. The email field validates on keyup with a 500ms debounce (delay:500ms), preventing excessive server requests while still providing real-time feedback. The subject dropdown dynamically loads additional form fields based on the selection. On submission, the entire form is replaced with either a success message or a re-rendered form with validation errors. The user experience rivals any SPA, yet there is zero JavaScript to maintain on the client side.

htmx vs Traditional JavaScript Frameworks

To understand where htmx fits in the ecosystem, it helps to compare it directly with the frameworks most developers are familiar with. Our roundup of the best web frameworks for 2026 covers the full spectrum, but here is how htmx stacks up on specific dimensions:

Bundle Size and Performance

htmx weighs approximately 14KB gzipped. Compare this with React (42KB + ReactDOM), Vue 3 (33KB), or Angular (143KB). When you factor in the state management libraries, routers, and build tooling that frameworks typically require, the gap widens further. Because htmx leverages server-side rendering, the browser does less work overall, which translates to faster initial page loads and better web performance scores.

Developer Experience

With traditional frameworks, developers must learn JSX or template syntax, component lifecycle methods, state management patterns, routing, build configuration, and often TypeScript on top. With htmx, the learning curve is a handful of HTML attributes. Any developer who understands HTML and HTTP can be productive with htmx within hours, not weeks.

Architecture

JavaScript frameworks push you toward a client-server architecture where the front end is essentially a separate application consuming a JSON API. htmx uses a server-centric architecture where the server returns rendered HTML. This means you can use any server-side language — Python, Ruby, PHP, Go, Java, C# — and leverage its templating engine directly. There is no need for a separate API layer or data serialization format.

SEO and Accessibility

Because htmx applications are fundamentally server-rendered HTML pages with progressive enhancement, they are inherently SEO-friendly and accessible. There is no hydration step, no blank page while JavaScript loads, and no reliance on client-side rendering for content. Search engines see fully rendered content on the first request, and screen readers work naturally with the semantic HTML structure.

When to Use htmx (and When Not To)

htmx is not a universal replacement for JavaScript frameworks. It excels in specific scenarios and is less suitable for others. Here is an honest assessment:

htmx Shines For

• Content-driven websites — Blogs, news sites, documentation portals, and marketing pages that need dynamic features like search, filtering, or infinite scroll.
• CRUD applications — Admin panels, dashboards, and internal tools where the primary interaction pattern is creating, reading, updating, and deleting records.
• E-commerce — Product catalogs, shopping carts, and checkout flows where server-side rendering provides better SEO and performance.
• Progressive enhancement — Adding interactivity to existing server-rendered applications without a full rewrite. If your project is built with Django, Rails, Laravel, or Spring, htmx integrates seamlessly.
• Small teams — When you do not have dedicated front-end and back-end developers, htmx eliminates the need for a separate front-end codebase. Teams managing projects with tools like Taskee can streamline their development workflow significantly by reducing the number of moving parts.

Consider Frameworks Instead For

• Highly interactive UIs — Applications like Figma, Google Docs, or complex data visualization dashboards where real-time client-side manipulation is essential.
• Offline-first applications — Progressive Web Apps that need to function without a network connection require client-side state and logic that htmx cannot provide.
• Complex client-side state — If your application has deeply nested, interdependent state that changes frequently (think spreadsheets or collaborative editing), a client-side framework with a virtual DOM is more appropriate.
• Mobile applications — If you need to share code between web and native mobile apps, React Native or similar cross-platform frameworks are the right choice.

Advanced htmx Patterns

Beyond the basics, htmx supports patterns that enable sophisticated application behavior:

Out-of-Band Swaps

Sometimes a single server response needs to update multiple parts of the page. htmx handles this with out-of-band (OOB) swaps. By adding hx-swap-oob="true" to elements in the response, htmx will swap them into matching elements on the page regardless of the primary target:

<!-- Primary response content (swapped into hx-target) -->
<div id="main-content">
  <p>Order confirmed! Your order number is #12345.</p>
</div>

<!-- Out-of-band: updates the cart count in the header -->
<span id="cart-count" hx-swap-oob="true">0</span>

<!-- Out-of-band: updates the notification badge -->
<span id="notifications" hx-swap-oob="true">1 new</span>

WebSocket and SSE Integration

htmx includes extensions for WebSocket connections and Server-Sent Events, enabling real-time updates without additional libraries. This makes it viable for chat applications, live dashboards, and notification systems — use cases that previously demanded a full JavaScript framework.

Request Headers and Extensions

htmx sends useful headers with every request, including HX-Request, HX-Target, HX-Trigger, and HX-Current-URL. Your server can inspect these headers to determine whether a request came from htmx and respond accordingly — returning a full page for standard navigation or a partial fragment for htmx requests. This pattern makes it trivial to support both JavaScript-enabled and JavaScript-disabled clients from the same endpoints.

Integrating htmx with Backend Frameworks

One of the most compelling aspects of htmx is how naturally it integrates with server-side frameworks. There is no need for a separate API — your existing routes and templates work with minimal modifications.

Django and htmx

The Django ecosystem has embraced htmx enthusiastically. The django-htmx package provides middleware that detects htmx requests and makes the htmx-specific headers available on the request object. You can check request.htmx to determine whether to return a full page or a partial template.

Rails and htmx

Ruby on Rails, with its strong convention-over-configuration philosophy and built-in template rendering, is a natural fit for htmx. Turbo (part of Hotwire) follows a similar philosophy, but htmx offers a more framework-agnostic approach that some developers prefer.

Laravel and htmx

Laravel’s Blade templating engine works beautifully with htmx. You can use Blade partials as htmx response fragments, and Laravel’s form request validation integrates cleanly with htmx’s error handling patterns.

Go and htmx

Go’s standard library html/template package, combined with htmx, creates an extremely lightweight and performant stack. The Go community has produced several htmx-friendly templating libraries that make building dynamic applications feel effortless.

For teams and agencies building web projects, pairing htmx with a robust backend framework can dramatically accelerate delivery timelines. Web development agencies like Toimi have been exploring how simplified front-end architectures reduce both development time and long-term maintenance costs.

htmx and the Return to Simplicity

The rise of htmx is part of a broader movement in web development toward simplicity and pragmatism. After years of increasing complexity — build pipelines, transpilers, bundlers, package managers, virtual DOMs, hydration strategies — many developers are questioning whether the trade-offs are worth it for most applications.

htmx represents a return to the architectural patterns that made the web successful in the first place: the server generates HTML, the browser renders it, and hyperlinks and forms handle interaction. htmx simply extends this model with the capabilities that modern users expect — partial page updates, smooth transitions, and responsive interactions — without abandoning the simplicity of the original web model.

This philosophical alignment with the web platform also makes htmx a natural complement to approaches like Jamstack architecture, where server-rendered content and progressive enhancement are core principles.

Performance Considerations

While htmx is lightweight on the client, it does shift more work to the server. Each interaction that would have been handled client-side in a SPA now requires a server round-trip. Here are strategies to mitigate potential performance concerns:

• Edge rendering — Deploy your server close to users using platforms like Cloudflare Workers, Fly.io, or AWS Lambda@Edge to minimize latency.
• Aggressive caching — Use HTTP cache headers and ETags to let the browser cache htmx responses. htmx respects standard caching directives.
• Response compression — HTML fragments are highly compressible. Enable gzip or Brotli compression on your server for minimal transfer sizes.
• Connection pooling — htmx reuses connections efficiently, but ensure your server is configured with appropriate keep-alive settings.
• Optimistic UI — Use hx-disable and CSS transitions to provide immediate visual feedback while the server processes the request.

In practice, for most applications, the round-trip latency is imperceptible on modern networks. The total time from user action to rendered update is often faster than SPA frameworks because there is no client-side rendering overhead — the HTML arrives ready to display.

The htmx Ecosystem

htmx has a growing ecosystem of extensions and companion libraries:

• htmx extensions — Official extensions for class-tools, loading-states, multi-swap, path-deps, preload, and more.
• hyperscript — A companion scripting language (also by the htmx creator) for adding small bits of front-end interactivity when pure HTML attributes are not enough.
• Shoelace / Web Components — htmx works seamlessly with Web Components, letting you combine custom elements with htmx-driven interactivity.
• Alpine.js — For cases where you need more client-side logic than htmx provides but less than a full framework, Alpine.js pairs well as a complementary tool.

The relationship between htmx and jQuery is worth noting. jQuery revolutionized web development by simplifying DOM manipulation and AJAX calls. htmx takes this further by eliminating the need for scripting altogether for common patterns. If you are curious about jQuery’s legacy and ongoing relevance, our article on jQuery provides useful historical context.

Getting Started: A Practical Roadmap

If you are ready to try htmx, here is a practical roadmap for adoption:

1. Start with a single feature — Pick one interactive element in an existing project (a search box, a filter, a load-more button) and implement it with htmx. This lets you evaluate the approach with minimal risk.
2. Structure your server responses — Create a pattern for returning HTML fragments. Most server frameworks support partial rendering or template includes that map cleanly to htmx response expectations.
3. Add loading indicators — Use the htmx-indicator class and hx-indicator attribute to provide visual feedback. This is essential for a polished user experience.
4. Implement error handling — Configure htmx:responseError events and use appropriate HTTP status codes. htmx respects HTTP semantics, so return 422 for validation errors, 404 for not found, and so on.
5. Scale gradually — As you gain confidence, convert more features to htmx. You may find that entire sections of client-side JavaScript become unnecessary.

FAQ