Hello! This is not clickbait. I thought for a long time about what to call this article, but it is hard to convey in words what is felt. Therefore, I wrote simply as I felt.
For a long year we have been supplementing the template language, but the range of applied use was quite limited. We developed within the framework of the template paradigm, but, in essence, it was correct, but in an applied project it is still quite difficult to implement this without something serious.
By serious I mean a framework, or something like that, that supported the syntax by default, but, in fact, if jsx has react, then it is quite difficult to build a structure on it, since it itself is structural.
Therefore, we took a different path, which I will try to describe in this article 🔎
⚙️ Structural modules and the real DOM
Whatever anyone says, the time of template languages is a bit different. Today, many people look at artificial intelligence as something breakthrough. And it is, but the fact is that it is not everything in our world. About 10 years ago, there was active development of various template languages, but now you are more likely to find 1000 new AI projects than one with templates.
And this is not surprising, because with the advent of jsx, ejs and handlebars, we can consider that this topic has exhausted itself and humanity can no longer come up with anything better. Maybe it is so, but only in some aspects. We interact with the server in the same way, and php to js, no matter how much you want, you can’t normally attach it.
So, as an experiment, we created this project to move this topic forward.
<div class="container">
{{#request src="/api/my-component.html"}}
{{#indicator trigger="pending"}}
<p>Loading...</p>
{{/indicator}}
{{/request}}
</div>
HTMX, no matter what SEO techniques they use and how caricatured they are in some sense, have nevertheless proven over 10-12 years of work on the topic that this topic is truly relevant in development. Together with Alpine.js, we see that not all people want to work on frameworks. This is correct, but it is also difficult and cumbersome on the other hand.
This topic, for some reason, was actively developed in attributes 3-4 years ago, but for some reason no one looks at template languages. It's as if the hype on them passed 10 years ago and everyone thinks that they are relics of the past, but this is not so.
We believe that this topic is not forgotten, but we cannot deny the fact that today most of such projects are based on working with the real DOM. There is simply no escape from this.
🔥 Hype on attributes
Anyone who thinks that in the world of development hype can be out of nowhere is wrong. Today, there are facts that in the state of the market today, people are not ready to switch to something more monumental, since it is easier to sit down at the framework. Therefore, working with the real DOM, when we connect only a couple of files - this is important. If you remember the same Docsify, to create documentation you do not need to install a bunch of packages that are not related to JS at all, as is done with Jekyll, this is the whole point.
Therefore, no matter how much we develop the theme of the template language, in a vacuum it is quite difficult to use, therefore, in fact, an obvious decision was made to supplement the functionality with a new module, which is called hmpl-dom.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Example</title>
</head>
<body>
<main>
<template hmpl>
<div>
{{#request src="/api/my-component.html"}}
{{#indicator trigger="pending"}}
<p class="indicator">Loading...</p>
{{/indicator}}
{{/request}}
</div>
</template>
</main>
<script src="https://unpkg.com/json5/dist/index.min.js"></script>
<script src="https://unpkg.com/dompurify/dist/purify.min.js"></script>
<script src="https://unpkg.com/hmpl-js/dist/hmpl.min.js"></script>
<script src="https://unpkg.com/hmpl-dom/dist/hmpl-dom.min.js"></script>
</body>
</html>
Thanks to him, we combined the approach of a template language with working with a real DOM. I am convinced that attributes by definition, no matter how extensible they seem (like in Alpine.js, when you write expressions with functions there), they cannot be a full-fledged replacement.
Yes, they have their advantages, but it's not about them, it's about working with the real DOM without js.
👀 What if I need to pass RequestInit?
No one will move away from js, even in such an implementation. Its meaning is in the choice of using js or not, as well as in the simplicity that is currently on the market.
index.html
<template data-hmpl data-config-id="clicker-config">
<div>
<button data-action="increment" id="btn">Click!</button>
<div>
Clicks: {{#request src="/api/clicks" after="click:#btn"}}{{/request}}
</div>
</div>
</template>
script.js
import { init } from "hmpl-dom";
init([
{
id: "clicker-config",
value: {
compile: { memo: true },
templateFunction: ({ request: { event } }) => ({
body: JSON.stringify({
action: event.target.getAttribute("data-action")
})
})
}
}
]);
We can still pass everything that was done before. It's just another level of nesting, when we had it before only within one compile function, now in a whole connected chain of templates, where a separate templateFunction is created for each (yes, we wouldn't take outerHTML from the entire page, because that would be just stupid.
🔗 Links
More about this project you can find here:
Also, if you want to support us, you can put a star on our main project. Thanks!
💬 Feedback
We would be very grateful for your assessment of this module and the whole idea of working with real DOM. ❤️
Thank you for reading this article!
Top comments (22)
"Without JavaScript"
Well, it’s clear that you can’t do without it, but in practice you can’t use it.
I see.
So Javascript is used in the templating, events handling and script functions but i wll not have the freedom to use it.
"without javascript" besides not being true, do you really see this is an advantage?
What I think probably doesn't bother anyone. It's just that it's necessary for the projects, so we did it.
I asked the author of the project if he thought that choice X was really the best.
He said that no one cares what he thinks.
... Ooooooooooook.
The market decides
XD market decided on React long time ago, which still keeping the jobs alive
Congratulations!
good
Thanks!
this is extremely impressive, honestly feels like you’re pushing in a direction most people forgot about awhile back. i always end up coming back to this question though: what tradeoff would you never accept for the sake of keeping things this simple
Yes
Eh. While quite impressive, this is pretty useless for the vast majority of apps. Why reinvent the wheel for the 1000th time?
So, we do not create a wheel. This is just an expansion of the functionality with an additional module. I think it will be useful.
Interesting to read
Yes
I simply use web components for this use cases. I try to avoid frameworks as much as possible in my web apps.
Nice for the update.
Thanks! Yes, I think so
Today, we present one of the most important modules for us in general! Like version 3, we continue to approach the ideal convenience in development.
There is a big rush to replicate Microsofts Blazor which is an established technology that uses sockets and server side rendering of html so only the Dom diff is sent to the browser. Its blazing fast with Razor hence Blazor. Ive seen loads of Frontend devs scared avout thier jobs because it means React, Vue, Angular, Node is not needed. No Javascript in Blazor no concept of web requests and full page refresh f5 etc. So there are few framework makers looking to make new replacements to emulate Mictosoft. But essentially now backend devs dont need frontend javascript devs anymore. This whole concept of SignalR and server side rendering has rocked the javascript world. Ive been using Blazor commercially for years now we dont employ javascript devs no need.
Hello AngularJs once again