What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
htmx 4 lets ordinary HTML elements send HTTP requests and place the HTML that the server returns into the page. Many interactions, such as refreshing a fragment, submitting a form inline, or deleting a list item, can be built this way without writing a separate fetch handler for each one.
The phrase “without JavaScript” needs one precision. htmx is itself a JavaScript library, delivered as a single file with no dependencies. What it removes is most of the custom client-side script you would otherwise write for common page updates. You still write HTML, the server still produces the HTML fragments, and you still need to understand HTTP and the browser.
Install htmx 4.0.0 on purpose
The htmx project announced version 4.0.0 on 28 August 2026. Its announcement says that version 2.x stays on the npm latest tag and version 4.0 stays on next until some point in early 2027. The aim is to avoid silently upgrading people who load htmx from unversioned CDN URLs. For that reason, do not assume that latest or an unversioned URL means 4.x. Pin the version you tested.
htmx is distributed as one JavaScript file with no dependencies, and the project’s documentation says no build step is needed for basic use. There are three ways to load it:
| Method | How to do it | When it suits you |
|---|---|---|
| Versioned CDN | Add a script tag that points to a versioned htmx 4.0.0 build. Copy the exact URL from the htmx documentation rather than building one by hand. | Prototypes and small pages where you want no local files. |
| Vendored file | Download the htmx 4.0.0 file and place it in your static assets folder, then reference it locally. | Production sites. The documentation suggests considering self-hosting in production. |
| npm | Run npm install htmx.org@4.0.0 in your project folder, then serve the file from your bundle or static directory. |
Projects that already manage dependencies with npm. |
Build your first interactive element
Here is the smallest useful example. A button fetches a time fragment from the server and places it inside a container.
<script src="/static/htmx.min.js"></script>
<button hx-get="/clock" hx-target="#clock" hx-swap="innerHTML">
Refresh time
</button>
<div id="clock">Not loaded yet</div>The script path above is a placeholder for wherever you placed the file. Work through the interaction in this order:
- Load the htmx 4.0.0 script once, in the page head or before the closing body tag.
- Add
hx-get="/clock"to the button. When the button is clicked, the browser sends a GET request to/clock. - Add
hx-target="#clock"to say which element receives the result, andhx-swap="innerHTML"to say that the returned HTML replaces the contents of that element. - On the server, make the
/clockroute return an HTML fragment such as<span>14:05:22</span>. Do not return a full HTML document, or the full document will be inserted into the container.
To trigger on a different event, add hx-trigger. It changes which browser event starts the request, while hx-target and hx-swap still control where and how the response lands.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteHow the request-and-swap cycle works
A normal link already works this way: it sends a GET request and loads the returned page. htmx extends that idea in two directions. Any element, not only links and forms, can issue a request. And the response can replace only the part of the page you choose, not the whole document.
In practice, every htmx interaction follows the same four steps: markup describes the interaction, the browser sends an HTTP request, the server responds with HTML, and htmx swaps that HTML into the document. This suits server-rendered, hypermedia-oriented interfaces. It does not mean the application can avoid client-side scripting altogether, and it does not replace knowledge of HTTP, browser behavior, or JavaScript as a runtime.
What changed in htmx 4
The release announcement highlights three user-facing changes: attribute inheritance is explicit by default, event names are standardized, and history support no longer uses localStorage by default. The internal move from XMLHttpRequest to the native fetch API should be transparent for most users, though you should still test your interactions after upgrading.
| Area | What htmx 4 does | What to check in your code |
|---|---|---|
| Attribute inheritance | Inheritance is explicit by default. Attributes that should flow down the DOM tree need the :inherited suffix. |
Review attributes placed on containers and confirm that children still receive the behavior you expect. |
| Event names | Names are standardized. For example, htmx:afterRequest becomes htmx:after:request. |
Update every event listener that uses the old names. |
| Removed APIs | htmx.addClass() has been removed. |
Replace calls with the native element.classList.add(). |
| History | Pages are not cached in localStorage by default, and back navigation re-fetches page content. The optional hx-history-cache extension caches locally using sessionStorage. |
Check any page that assumed back navigation would return instantly from cache. Enable the extension if you need that behavior. |
Run the upgrade check first
If you are moving an existing htmx 2.x project, run the check that the release announcement provides:
npx htmx.org@4.0.0 upgrade-checkThe upgrade guide covers additional breaking changes and new attributes beyond the table above. Read it before you change production templates.
Best Value
Optional capabilities
The official 4.x documentation describes extensions for server-sent events, WebSockets, downloads, and compatibility with Alpine.js. It also describes hx-live, introduced with htmx 4, as a DOM-oriented reactive scripting option. Treat all of these as optional. A first page needs only the script, the request attributes, and a server that returns fragments.
Security: htmx makes HTML more powerful
Because htmx makes HTML more expressive, an attacker who can inject HTML into your application may be able to misuse that expressiveness. htmx does not replace careful server-side input validation or output escaping. Using attributes instead of scripts does not make an application secure by itself.
Size claims and further reading
The htmx homepage describes the library as small, at about 16k minified and gzipped, dependency-free and extendable. It also says the code base is 67% smaller than an equivalent React code base. This is the project’s own claim. The homepage does not describe how the comparison was measured, so treat it as a claim from the project rather than an independent result. The homepage also mentions the book Hypermedia Systems as background on building hypermedia-driven applications with htmx. It is optional reading, and this article did not verify its current availability or pricing.
Quick Recap
Choose htmx for the right kind of project
| Factor | Favors htmx | Favors a client-rendered application model |
|---|---|---|
| Rendering | Server renders HTML and the page changes in parts. | The browser renders most of the interface from data. |
| Custom JavaScript | You want to write little or no script for common updates. | You need extensive client-side state and logic. |
| Migration | You can run the htmx 4 upgrade check and update inherited attributes and event names. | You already depend on a framework’s component model. |
| Deployment | You can host a pinned htmx file yourself or use a versioned CDN URL. | Your build pipeline already bundles every front-end dependency. |
|
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
