Anthony Max

for HMPL.js

Posted on Apr 21

📢 HMPL v3.0: New big update!

#webdev #javascript #programming #opensource

Everything was heading towards this day and finally the 3rd major version of the template language was released, completely changing the whole concept!

The maximum in syntax has been achieved, and it is necessary to expand not only the capabilities of the query, but also the language as a whole.

In this article, you'll learn what's new and how it can help you save tons of disk space for your web application.

Let's get started!

👀 What is the problem with the old version?

The main reason for such a big update is of course the way the code itself looks and is written. You might look at this example and wonder what's wrong:

<div>
  <button data-action="increment" id="btn">Click!</button>
  <div>Clicks: { { src:"/api/clicks", after:"click:#btn" } }</div>
</div>

Yes, you might say that this syntax is normal because we are sort of passing the object in single brackets {...}, but in fact, after six months, I realized that this is not the case.

The main problem with this syntax is that it is not extensible and also hard to understand at first glance. Yes, it is very lightweight, but nevertheless, it is really just clumsy.

{{ src:"/api/clicks" }}

Conventionally, if you look at it this way, our properties are not assigned to anything. That is, when working with Vue, Handlebars and other projects, we are used to having some variable names or something from js in double quotes {{...}}, but here it is not read at all!

✅ How was this resolved in version 3?

There was a lot of thinking about this. Perhaps, different options were tested for a couple of months, but only in building a plan, already in the last two weeks the optimal option for writing code was found by trial and error:

<div>
     <button data-action="increment" id="btn">Click!</button>
     <div>Clicks: 
       {{#request
         src="/api/clicks"
         after="click:#btn"
       }}{{/request}}
     </div>
 </div>

Now from specific objects the syntax moves to components {{#request}}{{/request}} and their short version {{#r}}{{/r}}, which take values as attributes that we write to a regular js object.

And this is actually a very important thing, because all sorts of cycles, decorators and other functionalities are being conceived that will look simply awful with the original objects.

Also, despite everything, we are still working with the DOM structure, that is, tree tags, which all web developers are accustomed to, and adding such an uncharacteristic syntax as objects introduces a little confusion.

🌱 Checkout HMPL ★

⏱ What else was added in version 3?

Also, in the third version, interval sending of a request to the server was finally implemented.

import hmpl from "hmpl-js";

const templateFn = hmpl.compile(
  `<div>
      <button data-action="increment" id="btn">Click!</button>
      <div>Clicks: {{#request
        src="/api/clicks"
        after="click:#btn"
        repeat=false
        interval=1000
      }}{{/request}}</div>
  </div>`
);

let i = 0;
const clicker = templateFn(({ request: { event, clearInterval } }) => {
   if(++i > 10) clearInterval();
   return { body: JSON.stringify({ action: event.target.getAttribute("data-action") })
 }
}).response;

document.querySelector("#app").append(clicker);

Now, the module allows you to create periodically updated components, such as, for example, exchange rates, text from online broadcasts and much more.

📦 How can all this help you?

The most important thing in program development, one way or another, is ease of use and perception. No matter how cool your module is, you will not be able to expand if it is crude and boilerplate with some kind of incomprehensible code.

As an example, I can give class components in React, which gave and still give full control over the component life cycle thanks to 20 properties like componentDidMount, etc. But no one uses them, because they look terrible and are perceived simply not as js, but as a C++ class or something like that.

(w3cschools)

Also here, working with the template language, I can no longer simply perceive these brackets as request, but with a component that is called that way, then it is easy. Also here.

Also, don't forget the main point of the module:

Default markup:

<main>
    <header>
        <div class="header-container">
            <a href="/" class="logo">My<span>Site</span></a>

            <button class="mobile-menu-btn" aria-label="Toggle menu">☰</button>

            <nav id="main-nav">
                <ul>
                    <li><a href="/">Home</a></li>
                    <li><a href="/about">About</a></li>
                    <li><a href="/services">Services</a></li>
                    <li><a href="/portfolio">Portfolio</a></li>
                    <li><a href="/contact">Contact</a></li>
                </ul>
            </nav>
        </div>
    </header>
</main>

HMPL markup:

<main>{{#request src="/api/header"}}{{/request}}</main>

🖋️ Specification

Also, a convenient specification has appeared which, like a serious document, describes the essence of the work without amateurism.

You can see it here.

💬 Feedback

You can write your thoughts about the new features in the comments, it will be interesting to read! Or, there is a thematic Discord channel for questions and suggestions, there I or someone else will try to answer!

✅ This project is Open Source

So you can take part in it too! This also means you can use it for commercial purposes:

Repo: https://github.com/hmpl-language/hmpl
Website: https://hmpl-lang.dev
Full list of changes: https://hmpl-lang.dev/changelog.html

Thank you very much for reading the article!

Top comments (7)

Nevo David • Apr 23

pretty cool seeing you push out big updates like this, makes me wanna mess around with new ways to do stuff myself - ever hit a point where you rethink everything and wanna start from scratch or you always tweak bit by bit?

Anthony Max • Apr 23

Hi, Nevo! From the first version released a year ago until now, the project started "from scratch" twice. It seems to me that there are moments when you hit the ceiling of possibilities and you need to change something. Remember the same Next.js with app and pages.

Anthony Max • Apr 23

I remember myself, if I'm not mistaken, that Postiz didn't start right away. You also had the first version of what we have now, but it "didn't work" as described, so you, as I understand, deleted it and simply renamed it Postiz, changing it a bit there. I think that if something doesn't work, then it needs to be changed completely, but based on what has already been done.