HTMX - Web Apps Without the JavaScript Nightmare

React is 200KB of dependencies for a contact form. HTMX is 14KB and uses HTML you already know.

HTMX lets you build dynamic web apps without writing JavaScript. Instead of onClick handlers and state management hell, you add HTML attributes like hx-get and hx-post to make AJAX requests.

Carson Gross released this in 2020 after getting fed up with the JavaScript ecosystem. Started as a side project, now companies like GitHub and 37signals are using it in production. Turns out a lot of developers were as tired of React's bullshit as Carson was.

The catch? Every click hits your server. Make sure your backend can handle it or your users will hate you.

How It Actually Works

HTMX turns any HTML element into an AJAX trigger. Click a button? It posts to your server. Server returns HTML? HTMX swaps it into the page. That's it.

Instead of sending JSON back and forth like SPAs, your server returns HTML fragments. No client-side templating. No state synchronization headaches. The server controls everything, just like 2005, but with better UX.

Except when it doesn't. I spent like 6 hours, maybe more, debugging some form that just wouldn't submit. No error messages, no console warnings, just nothing. Turns out CORS was blocking requests and HTMX was failing silently. The server logs just showed Access to XMLHttpRequest blocked by CORS policy. Spent forever thinking I'd screwed up the HTML before I checked the Network tab.

Here's The Most Basic Example

<button hx-post=\"/api/like\" hx-target=\"#like-count\" hx-swap=\"innerHTML\">
  Like this post
</button>

Click the button → POST to /api/like → server returns <span>42 likes</span> → HTMX finds the #like-count element and replaces its content. No JavaScript, no event handlers, no bullshit.

The 14KB library handles DOM updates, request management, and all the AJAX plumbing you don't want to write. Until it breaks and you're staring at empty responses wondering what went wrong.

Bundle Size Reality Check

HTMX is 14KB gzipped. React starts at 30KB for "Hello World" but grows fast once you add routing, state management, and the 47 packages you actually need in production.

Performance benchmarks show HTMX apps load faster initially, but every interaction hits the server. Fast initial load, slower clicks. Your users will notice the delay if your backend is garbage.

HTMX 2.0: What Changed

HTMX 2.0 shipped in June 2024. The big changes:

• IE11 support dropped - Finally. Nobody cares about IE11 in 2025.
• Extensions moved to separate repo - Less core bloat, faster releases
• Security fix - selfRequestsOnly now defaults to true, preventing cross-domain requests
• Better module support - Works with ESM, AMD, CJS without hassle

Most existing HTMX 1.x code works unchanged. The breaking changes are small and well documented. Check the complete changelog for full details.

But here's what they don't tell you: upgrading from 1.9 to 2.0 completely fucked our file upload feature. Took me and Jake most of a day to figure out that the new selfRequestsOnly default was blocking uploads to our CDN. Classic "backwards compatible" upgrade that breaks production at 2pm on a Friday.

HTMX is stupidly simple to add to any page. No build process, no webpack config that takes 3 hours to understand, no npm install installing half the internet for a contact form.

Installation: Copy This Line

<script src="https://unpkg.com/htmx.org@2.0.6/dist/htmx.min.js"></script>

That's it. Put it in your HTML head and you're done. No build step.

If you're using npm because your company mandates it:

npm install htmx.org

Note: There's an old broken package called just htmx. Don't use it. You want htmx.org.

Core Concepts You Need to Know

HTMX extends HTML with attributes that define interactive behavior:

• hx-get, hx-post, hx-put, hx-delete: Specify HTTP methods and URLs
• hx-trigger: Define when requests occur (click, submit, custom events)
• hx-target: Specify which element receives the response
• hx-swap: Control how content is inserted (innerHTML, outerHTML, append)

Here's the basic example that won't break:

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

Server-Side Reality

HTMX applications require servers that can return HTML fragments rather than JSON. This works naturally with server-side rendering frameworks:

• Python: Django, Flask, FastAPI with template engines
• PHP: Laravel, Symfony with Twig/Blade
• Ruby: Rails with ERB/Haml
• Java: Spring Boot with Thymeleaf
• Go: Templates with html/template
• Node.js: Express with any template engine

The server handles routing, authentication, and business logic while returning appropriate HTML responses for HTMX requests.

The Workflow Trade-offs

HTMX trades JavaScript complexity for server complexity:

• No build process - Edit HTML, refresh browser. That's it.
• No client state - Your backend holds all the state. Hope it's fast.
• Different debugging - When HTMX breaks, you debug HTML responses in Network tab
• Testing changes - Less frontend testing, more integration testing
• Backend bottleneck - Every click hits your server. Optimize accordingly or prepare for angry users.

The workflow is great until it breaks and you have no idea why. I've wasted entire afternoons staring at the Network tab seeing no requests at all, thinking I'm going insane. Usually turns out I fucked up the target selector or the server was rejecting the request for some CORS bullshit I never figured out.