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!
tosh•6mo ago
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.
aanthonymax•6mo ago
Alpine.js, HTMX and HMPL - represent the same idea (if we are talking about the server), but differ in details.
tosh•6mo ago
When you say customizable: how? Can you give an example?
aanthonymax•6mo ago
rendall•6mo ago
aanthonymax•6mo ago
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);
aanthonymax•6mo ago