Hello everyone! In this article we will consider such a javascript module as HMPL and how it can replace HTMX in a project. Also consider their differences, advantages and disadvantages.
When further comparing the two modules, it is worth considering that one is a template language, while the other is a set of tools for working with HTML, implemented through attributes and more.
Let's start with the general concept for the two modules.
🌐 About server-side rendering and client-side rendering
The HMPL module is similar in concept to HTMX. We can also take HTML from the server via API, thus replacing modern frameworks and libraries for creating UI. Let's take a small example illustrating the work of HMPL and HTMX, as well as a framework such as Vue.js:
Vue.js example:
createApp({
setup() {
const count = ref(0);
return {
count,
};
},
template: `<div>
<button @click="count++">Click!</button>
<div>Clicks: {{ count }}</div>
</div>`,
}).mount("#app");
Size: 226 bytes (4KB on disk)
HMPL example:
document.querySelector("#app").append(
hmpl.compile(
`<div>
<button>Click!</button>
<div>Clicks: {{ src: "/api/clicks", after: "click:button" }}</div>
</div>`
)().response
);
Size: 209 bytes (4KB on disk)
HTMX example:
<div>
<button hx-post="/api/increment" hx-target="#counter" hx-swap="outerHTML">Click!</button>
<div id="counter">Clicks: 0</div>
</div>
140 bytes (4 KB on disk)
Using a simple clicker as an example, we can see (with some caveats regarding server-side and client-side data, as well as html and js markup, but that's not the main idea) that we get the same interface, although the file sizes on the client will be completely different. This is precisely the main advantage of the approach to creating a ready-made, or template UI component on the server side, so that the site user can load it faster while preserving the result.
Now, let's remember how large applications today, well, or at least earlier (when server-side rendering was not so popular), could be obtained using frameworks and libraries. The same SPA (Single Page Application) generates all content via javascript, when in html we have literally one line, but the joke is that with 10 kilobyte html we get a javascript file of several tens of megabytes. Such a site, the first time users visit it, can take a long time to load.
For example, if a potential client wants to quickly order flowers, he will not wait 10-15 seconds for the delivery store website to load, he will go to another website where the website will load faster.
There are many more practical examples of how websites work that can influence the sales funnel. But the point is that the main thing is the speed and convenience of the interface, and here there are already differences in approaches. But it is better to do this in a separate article. Here we also consider a comparison of HMPL and HTMX.
👀 Why use HMPL and what are its advantages over HTMX?
In this section I will try to tell you about several main reasons why you may choose HMPL instead of HTMX in some cases. Also, if you want to support the projects, you can give a star to all two modules! Thank you ❤️!
1. With a similar idea of reducing code, the two modules differ in concepts. In the case of HTMX, on the one hand, we get a convenient tool for working with an existing DOM, but on the other, all this happens through HTML and is updated literally in real time. With great difficulty, through non-standard solutions, we can work more or less through javascript, and in fact, working with javascript is almost completely absent. In the case of HMPL, on the one hand, we can easily work with javascript; generate a custom RequestInit, create thousands of separate DOM nodes with the same server UI support as on HTMX, but on the other - all the work is done with code, which is not always convenient when you want to create projects faster. Let's take an example of code:
HMPL example:
import { compile ) from "hmpl-js";
const templateFn = compile(
`<div>
<form onsubmit="function prevent(e){e.preventDefault();};return prevent(event);" id="form">
<div class="form-example">
<label for="name">Enter your email: </label>
<input type="text" name="email" id="email" required />
</div>
<div class="form-example">
<input type="submit" value="Register!" />
</div>
</form>
<p>Email {
{
src:"/api/register",
after:"submit:#form",
}
} successfully registered!</p>
</div>`
);
const initFn = (ctx) => {
const event = ctx.request.event;
return {
body: new FormData(event.target, event.submitter),
credentials: "same-origin"
};
};
const obj = templateFn(initFn);
wrapper.appendChild(obj.response);
HTMX Example:
<script src="/path/to/htmx.min.js"></script>
<div>
<form hx-post="/api/register" hx-target="#notification" hx-swap="outerHTML">
<div class="form-row">
<label for="name">Enter your email: </label>
<input type="text" name="email" id="email" required />
</div>
<div class="form-row">
<input type="submit" value="Register!" />
</div>
</form>
<p id="notification"></p>
</div>
This example clearly shows that HTMX is more about maximizing the speed and shortening of code, while HMPL is something combined between HTMX and a modern framework or library for creating UI. We can say that we get a somewhat similar result, but taking into account that we can customize the request to the server. This is very important, because customization of the request in conjunction with fetch and work in javascript will allow you to work with a microfrontend, or in conjunction with another framework, or even with tests.
2. The HMPL syntax is also an advantage in its own way, because the request objects are not tied to any tag. When rendering, they are replaced with comments that do not clutter the DOM with unnecessary tags. Example syntax:
HMPL syntax:
<div>some text {{ src: "/api/getSomeText" }} some text</div>
HTMX syntax:
<div>some text <span hx-put="/api/getSomeText" hx-swap="outerHTML"></span> some text</div>
In some cases, it is not possible to assign an attribute to achieve the minimum file size with just short tags like p or s. Sometimes, you will have to use the template tag in the same table, and it, in turn, takes up a lot of characters in the file. In the hmpl syntax, there are always single curly brackets and then an object.
3. HMPL is built entirely on fetch requests, which were introduced as a standard in 2015. HTMX, for IE13 support, uses XMLHTTPRequest by default, which was introduced in 1999 in IE and 2000 in Mozilla Gecko with Netscape Navigator. The fetch function allows you to use modern javascript features in browsers, such as AbortController, signals, and more.
And, there are still a fair number of advantages, like a separate .hmpl file extension when working with webpack and others, but in my opinion, those that I highlighted are the most important. Webpack config example:
module.exports = {
module: {
rules: [
{
test: /\.hmpl$/i,
use: ["hmpl-loader"],
},
],
},
};
ℹ️ Disadvantages of HMPL
Also, hmpl has a number of disadvantages that I would like to talk about:
1. HMPL does not yet support WebSockets, which may complicate the implementation of code into the project. In HTMX, this support is present.
2. Since fetch is used, the layout will not be supported in some older browser versions.
3. HMPL is a new module, it can sometimes have bugs. HTMX, on the contrary, is tested due to its widespread use.
✅ Conclusion
The HMPL template language can replace HTMX in cases where flexible request customization is required, as well as direct work with nodes via JavaScript; If you, for example, want to create a cycle of 1000 identical nodes, and at the same time have the advantages of a server-oriented UI, then it will also suit the task. If the goal is to completely minimize work with JavaScript, or to use an established tested module and a simple connection to the server with a minimum amount of HTML code, then HTMX is good here.
Thank you all for reading this article!
Top comments (23)
Wait, we already need an alternative to HTMX? I thought HTMX was going to replace all the frontend frameworks?
you may have been the victim of a scam 🤪
I understand why XMLHTTPRequest in 2025 is due to
overrideMimeType, but it would seem that behind such a convenience lies the fact that the route can send you any type, and it will be overwritten instead of an error. Well, and we shouldn't forget about backward compatibility and other things either.I respect htmx, but with all the desire to say that it will replace, it would not be entirely correct. I just see what is being replaced (XMLHTTPRequest requests without almost any customization), especially when it comes to working with a server in 2025. I understand why this is so, because that's the whole point. In a certain simplicity and functionality, but, in my opinion, there are also disadvantages to this approach.
xkcd.com/927/
is alternative to alternative to alternative...
Is possible to work with a component in HMPL, and how?
I don't quite understand in what sense the word component is used here. If it is in the understanding of React a type of function that returns jsx markup (everything is conditional, because it returns a regular object), then HMPL is not connected with React and other frameworks and libraries. But, this does not mean that it cannot be used in conjunction with them. In React you can easily work through
refand there will be no problems.In bare simple HTML if I need to create a component ( repeated url element ), I wrote as template tag and a I used that clone for a greater speed.
If we take regular HTML, then HMPL with
templateis definitely good)Wait, these are all strings?
HTMX is all HTML.Vue and HMPL - js code with template strings. It was possible to show HMPL via HTML when a request object is simply passed, but I wanted to demonstrate the customization possibilities
Good article! I would also like to say something about PHP and compare.
Thank you! What does this have to do with anything now?)
I would also add online examples on codepen, but I think the code there is small, so it seems ok.
Thx for this article. When I need to choose between HTMX and HMPL according this article, my favorite is HTMX, because HTMX can use much more simpler. I just need to copy this HTML code to FE part to work it, and do not need further state or DOM handling, because HTMX solve that "problem".
Imho: a real raw level to make any webpage (FE perspective):
Well, according to the description of your task, maybe HTMX will be advantageous because it is easier to set up - I do not argue. But, if you still want to send custom requests and more fully control the process, then, as described in the article, I can offer you HMPL as an alternative. Trivially, if you just need to quickly transfer part of the code to HTML, then HTMX, yes, in principle, is the choice that is needed, but if we are talking about more or less complete work with js with process control, then, again, you can consider HMPL.
Don't make mistake, I never used a HTMX. Even I don't think that is a best way, because just a hide a lot of things, and you right a certain point you will be need to use external JS function for it.
My perspective of point is a multi page simple HTML with a minimal JS. Maybe a better than relally obviously page ( like a game where a custom realtime interaction is take a place ) I use some JSX based setup ( even without FW ).
I'm not discouraging anyone from using something. I'm just offering an alternative. HTMX is simpler from the start - yes. That's its feature. But I think that simplifying everything is not worth it either. For me, the golden mean is better, which is implemented in HMPL, when you don't write very big code, and have the ability to control the process of sending a request and work in js fully.
Thanks very much for the write up. You did a good job! Since I use it everyday at work, I would opine that HTMX is much more natural and much easier to read. It also has way more features than other alternatives.
Yes, more features. But you can't send custom requests to the server, and you also depend on the DOM. I don't argue that HTMX is easy to read, but this syntax has its downsides.
Take a look at HTMZ - it only weighs 166 bytes (yes, bytes) and is super flexible.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.