Requests are made via fetch and are configured via javascript almost entirely, which is what is needed today to work with the server.
The very essence of the template language comes down to minimizing the size of the bundle of the original web application by moving the components to the server and then storing them there. Thus, on the client we get a framework, where we insert components from the server brick by brick.
We showed this template language a long time ago, but it was not so mature then, so people had a lot of questions: https://news.ycombinator.com/item?id=41204552
Thank you very much to everyone for your attention! Please tell me what you think about the project? It will be interesting to know!
When you say it can replace htmx (which I’m using at the moment):
Isn’t this similar to htmx?
Like if I’m already using htmx, do I see benefits from switching?
Please correct me, but I’d rather frame HMPL, htmx and Alpine.js in the same camp?
So they are direct competitors and different flavors for the lightweight frontend approach.
But the main proposal of HMPL et al is to make people re-think if they need a huge and complex heavy frontend approach or if/when they should go for something lighter.
Alpine.js, HTMX and HMPL - represent the same idea (if we are talking about the server), but differ in details.
When you say customizable: how? Can you give an example?
const templateFn = hmpl.compile( `<div> <button data-action="increment" id="btn">Click!</button> <div>Clicks: {{#request src="/api/clicks" after="click:#btn"}}{{/request}}</div> </div>` );
const controller = new AbortController(); const clicker = templateFn(({ request: { event } }) => ({ body: JSON.stringify({ action: event.target.getAttribute("data-action") }), signal: controller.signal, })).response;
document.querySelector("#app").append(clicker);