TL;DR
I already wrote an article on how this module can be used to replace Next.js, but it was more of a light version in some cases.
Now, finally, we get to the specifics, where the replacement is completely relevant and not far-fetched. Both modules work with HTML from the server and have a similar concept, so this is definitely a good fit.
Today, we will be replacing HTMX in the project with HMPL.
Well, let's get started! 🏎️
⚙️ From simple examples
Let's start with the simplest example we can imagine - a clicker. You could do something like this:
<body>
<div class="clicker-container">
<h1>HTMX Clicker</h1>
<div class="click-count" id="counter" hx-swap-oob="true">0</div>
<button
class="click-button"
hx-post="/click"
hx-target="#counter"
hx-swap="innerHTML"
>
Click!
</button>
</div>
</body>
Looks good at first glance, and most importantly, it is functional. But now, let's take an example on HMPL.js:
<body></body>
<script>
const templateFn = hmpl.compile(`
<div class="clicker-container">
<h1>HMPL Clicker</h1>
<div class="click-count" id="counter">
{{#request src="/click" after="click:#btn"}}
{{/request}}
</div>
<button id="btn">Click!</button>
</div>
`);
const clicker = templateFn().response;
document.querySelector("body").append(clicker);
</script>
As we can see, we have two different approaches, where one module is completely dependent on the current DOM, and the second one is not, but is generated via JS. But, we see that in general, it is the same interface with a common approach. Only here, the first and main problem is that in the first case we have the minimum possible set of settings for the request.
🔍 Problems (intentional)
In HTMX, it was specially made so that the developer would depend minimally on js, so this is where the most serious problem of this module comes from - practically zero customization of the request.
So, yes, of course, you can send the body like this:
<button
class="click-button"
hx-post="/click"
hx-target="#counter"
hx-swap="innerHTML"
hx-vars='{"action": "increment"}'
>
Click!
</button>
But still, if we want something more, we see that it is impossible or difficult to implement. And, once again, this is intentional, because the whole point of the module is ease of use.
Also, the second problem is that we have requests, but they are sent via XMLHTTPRequest, a standard that is over 25 years old. Yes, the last addition was in the early 10s, but the fact is.
In HMPL, the almost completely customizable fetch is used, that is, consider that everything new in ECMAScript is already supported by default.
🔗 Complex example
Let's use a more complex example to show how else you can replace HTMX in a project.
<div id="wrapper">
<form
id="form"
hx-post="/api/register"
hx-target="#response"
hx-indicator="#loading-indicator"
hx-swap="innerHTML"
hx-include="this"
>
<div class="form-example">
<label for="login">Login: </label>
<input type="text" name="login" id="login" required /><br/>
<label for="password">Password: </label>
<input type="password" name="password" id="password" required />
</div>
<div class="form-example">
<input type="submit" value="Register!" />
</div>
</form>
<div id="response"></div>
<div id="loading-indicator" class="htmx-indicator">
<p>Loading...</p>
</div>
</div>
Here we now have a form that we send to the server. The hx-include attribute includes the data as FormData. Also, we have a request indication. Now, let's try to do the same in HMPL:
<body></body>
<script>
const templateFn = compile(
`<div id="wrapper">
<form onsubmit="function prevent(e){e.preventDefault();};return prevent(event);" id="form">
<div class="form-example">
<label for="login">Login: </label>
<input type="text" name="login" id="login" required /><br/>
<label for="password">Password: </label>
<input type="password" name="password" id="password" required />
</div>
<div class="form-example">
<input type="submit" value="Register!" />
</div>
</form>
<p>
{{#request
src="/api/register"
after="submit:#form"
repeat=true
}}
{{#indicator trigger="pending"}}
<div class="indicator">
<p>Loading...</p>
</div>
{{/indicator}}
{{/request}}
</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);
document.querySelector("body").append(obj.response);
</script>
Here it is clearly visible that we can do the same as in HTMX, but there is a small but, that we can work with the form, take any data from there and modify our request.
📊 Size comparison
I won't keep silent about this point, but it's still worth evaluating from this side. With HTMX you will write less. Let's compare the size of applications with a simple example:
📦 HTMX:
📦 HMPL:
Because everything is so minimal, HTMX is the undisputed leader in terms of size, but you can see that in this example the size of the application is not very critically different.
Although, compared to others, HMPL generally shows good results in terms of dimensionality:
But, of course, if we reduce the capabilities of js, essentially doing the bare minimum, then the size of the source files will be smaller.
✅ Conclusion
Of course, you can continue to use HTMX, but in this article I wanted to give an alternative to the existing option. Tasks are different and people do not always need the bare minimum in the size of the application and they are not always ready to sacrifice functionality because of this. When working with the server, you will still have to customize the request one way or another, if we are talking about large applications. But, everything depends on the task.
Thank you very much for reading this article ❤️!
What do you think about this alternative? It will be interesting to know in the comments!
Useful link:
Top comments (13)
Love this deep dive into how much more flexibility HMPL offers on request customization compared to HTMX.
Curious if there are still any scenarios where you'd reach for HTMX over HMPL, or have you fully switched?
When size is the only thing that matters, otherwise I choose HMPL
pretty cool seeing your breakdown, makes me rethink if i’m sticking with my stack out of laziness or actual need - you ever feel like it’s just habit that keeps you on one tool for ages?
Yes
Well, I just wrote an article about this.
Loved the alternative..
Like the styling from HTMX. Like the KISS convention from HTMX. Like the HTML approach from HTMX. So Hmpl is not for me.
Well, here it depends on what someone needs in the task - yes. But, it does not cancel the fact that with HTMX you will not be able to customize the request normally.
I think this is a great replacement.
Overview: The discussion emphasizes HMPL as a viable replacement for HTMX in web development, providing similar functionalities while being more customizable.
Modules Comparison
Simple Clicker Example
Key Problems Identified
fetchfor modern JavaScript featuresComplex Form Example
hx-includeto include form dataSize Comparison
Conclusion
made with love by axrisi
Some comments may only be visible to logged-in visitors. Sign in to view all comments.