• Home
  • About
Post header banner
User's profile
Anthony Max Published on Apr 21 • 4 min read

📢 HMPL v3.0: New big update!

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!

spec

👀 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>
Enter fullscreen mode Exit fullscreen mode

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" }}
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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.

class component
(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>
Enter fullscreen mode Exit fullscreen mode

HMPL markup:

<main>{{#request src="/api/header"}}{{/request}}</main>
Enter fullscreen mode Exit fullscreen mode

🖋️ 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!

thanks