HMPL.js Forem: HMPL.js

📢 We're opening a list of community projects! You can participate.

Anthony Max — Thu, 20 Nov 2025 20:08:33 +0000

Today we are pleased to finally present a great idea that has been around for a long time, but we never managed to implement it.

Constant delays due to new versions and other things have been somewhat of a drag, but now we're opening a list of community projects you can create or connect to.

🔎 What's the point?

There are many different lists on the internet with interesting projects in various programming fields, and we thought it would be a great idea to open one in our small community.

We've noticed that, in essence, to develop the project, people can not only write about it and contribute code to the main repository, but also create and develop their own applications using the template language.

Specifically for this purpose, we have also opened a section on the website where we also add information about such projects.

I think you'll find this interesting!

💬 Feedback

We value your opinion! Do you think a list like this would be of interest to developers, and why? It would be interesting to read.

🔗 Links

Major module update!

Anthony Max — Mon, 17 Nov 2025 17:13:38 +0000

Hello everyone! In this short article, I'd like to talk about the new versions we recently released.

It would seem that the modules are quite utilitarian and there is no particular point in updating them, but nevertheless, it is worth keeping them up to date today, and we will talk about some of the changes in them today.

Stay informed!

⚙️ vite-plugin-hmpl and hmpl-loader

In case you weren't aware, .hmpl actually has its own file extension. Loading it requires loaders, which were created specifically for Vite and WebPack. For these, we've updated the settings validation, which relies on the following types:

interface HMPLCompileOptions {
  memo?: boolean;
  autoBody?: boolean | HMPLAutoBodyOptions;
  allowedContentTypes?: HMPLContentTypes;
  sanitize?: HMPLSanitize;
  disallowedTags?: HMPLDisallowedTags;
  sanitizeConfig?: Config;
}

A small, but also quite interesting update.

🌳 hmpl-dom

This module is designed to use templating language syntax without npm or other add-ons. Nothing else is needed, just a single index.html file and that's it. In this update, we've added hmpl-dom.runtime.js.

This is also quite an update. They've also updated the README files and other texts everywhere, but that's not really important in the context of releases.

💬 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 (Star Us ★)
Website: https://hmpl-lang.dev
Full list of changes: https://hmpl-lang.dev/changelog

Thank you very much for reading the article!

New major HMPL version 3.2.0 🕶

Anthony Max — Wed, 12 Nov 2025 20:50:59 +0000

Today's vibe is to talk about the new version of the template language. We've been working on this project for a year and a half now, and, man, this is definitely the level of seriousness we're looking for.

You might think that after all this time, things could be done much better. That's true, but the fact is, what we have is really, really cool.

Let's take a look at the new version and see what we've prepared :)

🔗 Bind

Articles usually fill you with unnecessary fluff, whether on topic or not. I like to do that too, of course, but let's get straight to the most important thing.

<div class="{{requestStatus}} class1">Text</div>
{{#request
  src="/api/getHTML"
  bind="{{requestStatus}}"
}}{{/request}}

result:

<div class="hmpl-status-requestStatus-200 class1">Text</div>

Yes, now instead of indicators you can write custom classes and other attributes in general.

It's worth noting that the functionality itself is unique in that I took the code from Cample, a previous project that is one of the fastest on the internet. Working on it has finally helped me, as this speed will now also transfer to the template language implementation :)

Benchmark

👀 How is it with HATEOAS?

One of the key goals of a template language is to conveniently create applications on a HATEOAS architecture. That is, when we receive routes from our API that we can use to interact with the page.

{
  "id": 10,
  "name": "Lenovo Laptop",
  "price": 899.99,
  "inStock": true,
  "_links": {
    "self":        { "href": "/products/10" },
    "add_to_cart": { "href": "/cart", "method": "POST" },
    "category":    { "href": "/categories/laptops" },
    "related":     { "href": "/products?relatedTo=10" },
    "reviews":     { "href": "/products/10/reviews" }
  }
}

In this application paradigm, we understand that future versions of the template language will be aimed at convenient interaction with the server in this format. Because when we work in a regular application, we have to know all these routes, whereas here we simply describe the component, and then the necessary API routes are returned to us.

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

📢 HMPL v3.1: New major update!

Anthony Max — Sat, 25 Oct 2025 18:56:23 +0000

We've finally finished one of the most long-awaited updates, which brings us a little closer to one of the best tools for creating HATEOAS apps in the world (we hope)!

We've done a lot of interesting things with it. Since the project hasn't had any code updates for a while, this is a breath of fresh air that will boost its usability.

Today, we'll be talking primarily about app security, keeping apps up to date, and more. So, let's get started!

🔏 Improving security

When working with Hypermedia, unlike other tools, we pay special attention to the security of incoming data from the server. Therefore, one of our solutions was integration with DOMPurify, which cleans incoming HTML of potentially dangerous markup.

<!-- 
Response before:
<script></script>
<div>My component</div>
-->
<div>
  {{#request
    src="/api/get-my-component"
    sanitize=true
  }}{{/request}}
</div>
<!-- 
Response afer:
<div>My component</div>
-->

However, the problem arose that with default sanitizing we get fairly predictable application behavior, which is generally safe, but not flexible. Therefore, we introduce the sanitizeConfig property.

/**
 Response before:
 <div></div><math></math>
*/
const templateFn = compile("...",{
  sanitize: true,
  sanitizeConfig: { USE_PROFILES: { html: true } }
});
/**
 Response after:
 <div></div>
*/

It's based on Config with DOMPurify and allows, for example, blocking MathML from the application, as well as a lot of other customizations. This makes the tool truly comprehensive, and it will process even the most bizarre responses as the developer originally intended, without any boilerplate.

This property has been added to compile and is not planned to be moved to block helpers.

⚙️ Changing arguments for the get function

This is one of the most controversial changes, in my opinion, and one we've been thinking about for a long time. It would seem that if there are more than two arguments, then the properties should be immediately converted to an object, but this proved difficult.

before:

const elementObj = templateFn({
  get: (prop, value, context, request) => {
   ...
  }
});

after:

const elementObj = templateFn({
  get: ({ prop, value, context, request }) => {
   ...
  }
});

It would seem that you almost always use only two arguments in get, but if we were to work with the same context, we'd have to represent the arguments as an array and access them by index. Alternatively, we could specify unused variable names, but then linters wouldn't allow this code, so we believe the approach we've implemented is better.

We would just like to know your opinion, did we do the right thing?

💬 Feedback

✅ 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 (Star Us ★)
Website: https://hmpl-lang.dev
Full list of changes: https://hmpl-lang.dev/changelog

Thank you very much for reading the article!

📢 HMPL is participating in Hacktoberfest 2025!

Anthony Max — Thu, 02 Oct 2025 19:31:27 +0000

This is a submission for the 2025 Hacktoberfest Writing Challenge: Maintainer Spotlight

Hello everyone! This is the second year in a row that our project is participating in Hacktoberfest.

This is a huge milestone for us, as the project has grown quite significantly over this time. There's more code, it's become better, but most importantly, we've had the opportunity to work with so many great developers!

And this year, we'd like to do more, and we've prepared a huge number of cool tasks that you can complete.

Well, let's get started! 🏎️

👻 About the festival

This festival has been held since 2013. Here, you can discover a sea of interesting open-source projects, participation in which will give you valuable experience that will help you in your career.

There, you'll also be able to meet a wide range of developers from all over the world. And as a nice bonus, you'll receive badges that you can attach to your resume or to your GitHub README.

🌱 Our participation there

As I mentioned earlier, our first festival was in 2024. Back then, we were uploading an old repository. It had about 50 stars at the time. I'd show a screenshot, but the old Discord channel is now closed, so the messages there have been deleted. There are only forks of the old removed repository, but the pull requests are not preserved.

But still, back then, when I was working on the project alone, it was really cool to get a pull request from a developer for a fix to my code for the first time in my life! It just so happened to be Hacktoberfest time. Therefore, I am grateful to this festival.

👀 What now?

We've prepared a lot for today, so you can participate in the project's development! Here's a short list of what we've prepared for you:

🐛 We have 25+ issues that will suit both experienced users and beginners
🌱 If your pull request is successful, your GitHub profile will be posted on our website. You can share it with potential employers if you wish.

And also just respect from our team :)

🔗 Useful links

Repo: https://github.com/hmpl-language/hmpl (We would be glad if you give us a star☆)
Issues: https://github.com/hmpl-language/hmpl/issues
Official Hacktoberfest website: https://hacktoberfest.com

Thank you all for reading this article!

We'd be delighted if you'd like to become a contributor to our project!

LocalStorage vs SessionStorage vs Cookies: A Complete Guide 🗄️

Anthony Max — Wed, 06 Aug 2025 22:31:40 +0000

When we talk about such a topic as data storage, we immediately remember these 3 concepts. But here's the problem, we often use them unconsciously.

We are used to storing tokens in sessionStorage, but not everyone can answer why exactly. Other concepts follow the same scenario. All these issues have long been decided for us by the modules that we use, and this is sad, because you need to know about this, even if you do not understand websites at all.

In this article, I tried to prepare for you the ultimate guide so that you do not have any misunderstandings about what is used and for what.

Well, let's get started!

🗄️ LocalStorage

Before we start with LocalStorage, it's worth taking a short detour and talking about what storage is.

Simply put, storage is a dedicated place where the browser stores information. In JavaScript, such storages are represented as objects available via the window object’s properties with reserved names, or through dedicated variables.

Now, let's go back. There is a LocalStorage storage, which we access through the localStorage object. In this object itself, what is important now, the data is stored even when we close the tab or the browser itself. Suitable for large amounts of data.

// Save a value
localStorage.setItem("theme", "dark");

// Retrieve a value
const theme = localStorage.getItem("theme");
console.log(theme); // "dark"

// Remove a value
localStorage.removeItem("theme");

// Clear all storage
localStorage.clear();

It's a good place to store long-lived data, such as settings, cached data, etc.

🕓 SessionStorage

SessionStorage is similar to LocalStorage; the difference is that while localStorage is partitioned by origin only, sessionStorage is partitioned by both origin and browser tabs (top-level browsing contexts). The data in sessionStorage is only kept for the duration of the page session. Suitable for large amounts of data.

That is, if you close a tab in your browser, all your data in this storage will be cleared.

// Save a value
sessionStorage.setItem("authToken", "123456");

// Retrieve a value
const token = sessionStorage.getItem("authToken");
console.log(token); // "123456"

const templateFn = hmpl.compile(
  `<div>
    {{#request src="/api/my-component.html"}}
      {{#indicator trigger="pending"}}
        <p>Loading...</p>
      {{/indicator}}
    {{/request}}
  </div>`
);

const content = templateFn(() => ({
  body: JSON.stringify({ token })
})).response;

// Remove a value
sessionStorage.removeItem("authToken");

// Clear all storage
sessionStorage.clear();

Suitable for temporary tokens, as well as for data that is needed within the framework of while you are sitting at the site, that is, session data.

🍪 Cookies

And now, probably the most popular storage, which is on everyone's lips with modern web application users, is cookies. The banner with them is constantly displayed, but many miss the point: "what are they for?" In fact, this is a small storage (in size later), which stores temporary data (that is, data that will be deleted after a certain period). Suitable for small amounts of data.

// Set a cookie
document.cookie = "username=John; path=/; max-age=3600"; // expires in 1 hour

// Read cookies
console.log(document.cookie); // "username=John"

// Update a cookie
document.cookie = "username=Mike; path=/; max-age=3600";

// Delete a cookie
document.cookie = "username=; path=/; max-age=0";

This data is often used in all sorts of tracking on websites. How many people clicked, how someone moves the cursor, etc. Also, when working with authentication, this storage is often used.

✅ Conclusion

In this article, we looked at LocalStorage, SessionStorage, and Cookies, which perform different tasks for storing data in the browser. Choosing the right storage method depends on the lifetime of the data, the volume limitation, and the need to access it from the server. The right choice will allow you to improve performance, security, and the quality of the user experience.

Thank you very much for reading this article ❤️!

P.S. Also, don't forget to help me and star HMPL!

🌱 Star HMPL

📢 New Docs: How We Revamped Our Documentation with Astro Starlight 🌌

Anthony Max — Tue, 22 Jul 2025 22:50:03 +0000

Today is one of the most important days in the future development of the template language.

We have produced really comprehensive and clear documentation that looks very professional :)

In this article, I would like to consider the process of its creation, as well as tell you how you can make it and how it will be useful to you.

Let's get started!🏎️

👀 Why did we choose Astro Starlight for the new documentation?

I would like to point out that this is not an advertisement, no one paid us. So, let's be honest. Previously, we used VuePress. It is a really cool tool for creating documentation, but we encountered problems that we will describe below.

1. 💎 Design

First of all, it's the design. Just compare the design there and here:

VuePress

Starlight

Different people like different designs. These are two good designs, but we used a similar design for about a year. We literally got tired of it, so we chose the first option as the most popular today.

2. 🌊 Freshness

Still, we understand that VuePress needs to be replaced either with VitePress or with Docus from NuxtLabs (which recently joined Vercel). This point, with a full understanding of the two projects, also played a huge role in the choice of the platform.

We, one way or another, work on Vue for projects and are unlikely to choose something else for open source, but the fact is that we will not go anywhere from this design, which reminds us of it everywhere.

So, when we looked at other platforms, it wasn't profitable for us to switch to anything other than Vue, but we also needed something new. Starlight came out somewhere around 2023 (or was actively starting to promote itself), so we decided it was a good option.

3. Support for old files

All of VuePress was built on .md files. It was important for us to transfer it to a platform where it would also be. In the case of Astro, it does support data files. It was only necessary to make a header for old files, but, in general, it is not critical.

---
title: Introduction
description: Learn about HMPL
---

## How it works?

The HTML you use on your site is enhanced by adding special blocks that resemble components in syntax...

Also, a nice bonus in all this was that the problem with the {{code}} construct was no longer relevant. HMPL uses the following construction:

{{#request}}{{/request}}

And we had to wrap this expression in a pre tag quite often, so that it wouldn't cause errors when compiled into HTML. But, with Astro Starlight there is no such problem.

📚 New in documentation

In general, almost everything (except the content related to the technical part). New components: Tabs, Result, Steps and so on, all this makes the documentation literally a work of art.

With such components, it became much easier to understand how the module works. Previously, for the technical part, we used ecmarkup, but then we realized that it would not be able to give full control over the technical documentation, but just show what is obtained.

Also, almost all the texts were updated, a bunch of new things were added. It felt like a novel came out in terms of the number of words, not documentation 🥶

⚙️ How can you add this documentation to your project?

First of all, you will need to install Node.js version 18 or higher, and run the command:

npx astro add starlight

After this, you will need to configure the site config, which is located in astro.config.mjs, we can only show ours as an example:

// @ts-check
import { defineConfig } from "astro/config";
import starlight from "@astrojs/starlight";
import vue from "@astrojs/vue";
import starlightThemeNova from "starlight-theme-nova";

export default defineConfig({
  site: "https://hmpl-lang.dev",
  integrations: [
    vue(),
    starlight({
      title: "HMPL Documentation",
      description:
        "Server-oriented customizable templating for JavaScript. Alternative to HTMX and Alpine.js.",
      customCss: ["./src/styles/main.css"],
      logo: {
        src: "./src/assets/logo.svg"
      },
      expressiveCode: {
        themes: ["min-light", "min-light"],
        useStarlightDarkModeSwitch: false,
        shiki: {
          langAlias: {
            hmpl: "html"
          }
        }
      },
      components: {
        Search: "./src/components/Stars.astro"
      },
      editLink: {
        baseUrl: "https://github.com/hmpl-language/hmpl/edit/main/www/app"
      },
      favicon: "favicon.ico",
      social: [
        {
          icon: "github",
          label: "GitHub",
          href: "https://github.com/hmpl-language/hmpl"
        }
      ],
      sidebar: [
        {
          label: "Start Here",
          items: [
            { label: "Introduction", link: "/introduction" },
            { label: "Getting Started", link: "/getting-started" },
            { label: "Installation", link: "/installation" }
          ]
        }
      ],
      plugins: []
    })
  ]
});

And, there are most of the sidebar and other parameters that are repeated, I will not indicate all 200+ lines here.

✅ Conclusion

When choosing a documentation platform, it is important to consider many different things: from your past work to the number of people in the team. If we were to make documentation purely in Vue, it would take us a couple of months. In this article, we tried to show what kind of documentation can be made and how you can make it as cool as ours (well, we think ours is cool 👽)

🔗 Links:

Thank you very much for reading this article ❤️!

What do you think of the new documentation? It will be interesting to know in the comments!

P.S. Also, don't forget to help me and star HMPL!

🌱 Star HMPL

📢 HMPL-DOM v0.0.1 Released: Write Reactive HTML Without JavaScript

Anthony Max — Sun, 29 Jun 2025 21:19:34 +0000

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!

💎 Star HMPL ★

💬 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!

From 0 To 500 GitHub Stars: Our Year-Long Adventure🔥

Anthony Max — Thu, 19 Jun 2025 19:42:16 +0000

Hello everyone! Today, we would like to share a big event for us that happened the other day. Our project on GitHub received 500 stars!

This is really cool because a lot of effort was put into this project not only by me, but also by dozens of other contributors and thousands of people who liked, commented, and simply watched our journey for a long time.

There was a lot, from deleting the repository to opening new plugins for WebPack and Vite. In this article, I will try to briefly tell our path and also how we managed to get so many stars.

Well, let's not delay. Let's begin! 🚙

📚 History of HMPL.js

It all started with the idea of combining old developments of the Cample.js framework with the template language. The first steps were quite meager and before what the pattern language is now, was still very far.

There were several repositories and this is the second one we started in November last year. During this time, we spent most of the months simply developing the project, finishing some things. But only since February, we started to be active in social networks 🌐.

We have already written several articles about how growth has been going on over this time:

Today, it is interesting to look at the time, what was written then and now. There I tell in detail about what history was, but here there is no special sense in repeating.

👀 What is this project?

If anyone doesn't know, then HMPL is a small template language for displaying UI from server to client. It is based on customizable requests sent to the server via fetch and processed into ready-made HTML. What does this mean? It's probably better to show it in code:

import { compile } from "hmpl-js";

const templateFn = compile(
  `<div>
    <button class="getHTML">Get HTML!</button>
    {{#request
      src="/api/test"
      after="click:.getHTML"
      repeat=false
    }}
      {{#indicator trigger="pending"}}
        <p>Loading...</p>
      {{/indicator}}
    {{/request}}
  </div>`
);

const wrapper = document.getElementById("wrapper");

const elementObj = templateFn();

wrapper.appendChild(elementObj.response);

In essence, this is an add-on for HTML to implement a Server-Side Application. That is, this is not a render on the server, but the case when we mount components from the server on the client.

🌱 Why do people give stars to a project on GitHub?

I don't know myself, to be honest. Maybe the project is not bad, I don't know. But, in my opinion, first of all, people put stars because they see the project on their screen to begin with.

No matter how stupid it is, if a person doesn't see or hear something, then he doesn't know about it. But how can we make people know? Probably, writing on the Internet and telling people in person is the most effective option :)

Today, there are many ways to tell people about what you do. The most effective way for us to get the word out is dev.to, but you can also use:

🐈‍⬛ ProductHunt
🦋 BlueSky

And other social networks, there are simply a huge number of them today, just choose for any taste. The main thing, in any business, is frequency and quality. Do not think that one entry will be interesting to someone. This, as I have already realized on myself, is daily work.

❤️ And finally...

And don't forget to:

💎 Star HMPL.js on GitHub to support the project
💬 Join the HMPL Discord community for wishes, solving problems, and just communication

I replaced Alpine.js in my app with this alternative 🔥

Anthony Max — Tue, 17 Jun 2025 20:10:56 +0000

Typically, things like Alpine.js are compared to frameworks like Next.js because of their advantages over them.

Now we’re diving into something far more relevant. Both modules (Alpine.js and HMPL) work directly with HTML, and both are meant to bring logic closer to markup. That makes this comparison much more grounded.

Today, we're replacing Alpine.js in a project with HMPL.

Let’s get started! 🏎️

⚙️ From simple examples

Let’s start with the most basic clicker example. With Alpine.js, you’d probably write something like this:

<div
  x-data
  x-fetch:clicker="{
    url: '/click',
    method: 'POST'
  }"
  x-init="$fetch.clicker"
  class="clicker-container"
>
  <h1>Alpine Clicker</h1>  
  <div class="click-count" x-text="$fetch.clicker.data?.count ?? 0"></div>  
  <button class="click-button" @click="$fetch.clicker">Click</button>
</div>

It looks great and, most importantly, works. Now let’s look at the HMPL.js version:

<body></body>
<script>
  const templateFn = hmpl.compile(`
    <div class="clicker-container">
      <h1>HMPL Clicker</h1>
      <div class="click-count" id="counter">
        {{#request src="/click" after="click:#btn"}}
        {{/request}}
      </div>
      <button id="btn">Click!</button>
    </div>
  `);
  const clicker = templateFn().response;
  document.querySelector("body").append(clicker);
</script>

As you can see, we have two different philosophies: Alpine.js works declaratively inside the HTML itself, while HMPL compiles templates and dynamically renders them via JS. But the interface is conceptually similar - actions tied to events, data updates in the DOM. The difference lies in control and flexibility.

Also, it would be great if you supported the project with your star! Thanks ❤️!

💎 Star HMPL ★

🔍 Built-in limitations

Alpine.js, while powerful in its simplicity, isn't inherently built around a server-oriented paradigm. It's a client enhancement tool meant for light interactivity, not full templating or server-side rendering. This makes it great for progressive enhancement but somewhat limiting when building applications that rely heavily on server-driven content.

Because Alpine doesn't natively treat the server as a central part of the UI lifecycle, integrating complex request flows or handling server state often feels bolted on. Even with plugins like @alpinejs/fetch, you're still mostly wiring client-side logic, manually coordinating fetch calls, and managing reactive state in the browser.

This client-heavy approach can get cumbersome as your app scales. Form submissions, conditional loading, dynamic content updates, all require increasingly verbose JavaScript bindings or hacks involving x-init, external methods, and nested directives. Alpine gives you control, but often without abstraction.

In contrast, a templating language like HMPL is designed with the server at the core. It embraces server-rendered HTML and fetch-driven reactivity natively. You don't have to manually coordinate state or requests - it's declarative, context-aware, and built for scenarios where the server and the UI work in unison.

🔗 Complex example

Let’s take a more advanced example, a registration form with loading indicator. Here's what it might look like in Alpine.js:

<div x-data="formComponent()" id="wrapper">
  <form @submit.prevent="submit">
    <div class="form-example">
      <label for="login">Login: </label>
      <input type="text" name="login" id="login" x-model="form.login" required /><br/>
      <label for="password">Password: </label>
      <input type="password" name="password" id="password" x-model="form.password" required />
    </div>
    <div class="form-example">
      <input type="submit" value="Register!" />
    </div>
  </form>

  <template x-if="loading">
    <div class="indicator">
      <p>Loading...</p>
    </div>
  </template>

  <div id="response" x-text="responseText"></div>
</div>

<script>
  function formComponent() {
    return {
      form: { login: '', password: '' },
      loading: false,
      responseText: '',
      async submit() {
        this.loading = true;
        const res = await fetch('/api/register', {
          method: 'POST',
          body: JSON.stringify(this.form),
          headers: { 'Content-Type': 'application/json' },
        });
        const text = await res.text();
        this.responseText = text;
        this.loading = false;
      }
    };
  }
</script>

Now let's see how the same can be done in HMPL:

<body></body>
<script>
  const templateFn = hmpl.compile(`
    <div id="wrapper">
      <form onsubmit="event.preventDefault();" id="form">
        <div class="form-example">
          <label for="login">Login: </label>
          <input type="text" name="login" id="login" required /><br/>
          <label for="password">Password: </label>
          <input type="password" name="password" id="password" required />
        </div>
        <div class="form-example">
          <input type="submit" value="Register!" />
        </div>
      </form>
      <p>
        {{#request
          src="/api/register"
          after="submit:#form"
          repeat=true
        }}
          {{#indicator trigger="pending"}}
            <div class="indicator">
              <p>Loading...</p>
            </div>
          {{/indicator}}
        {{/request}}
      </p>
      <div id="response">{{response.body}}</div>
    </div>
  `);

  const initFn = (ctx) => {
    const event = ctx.request.event;
    return {
      body: new FormData(event.target, event.submitter),
      credentials: 'same-origin',
    };
  };

  const result = templateFn(initFn);
  document.body.append(result.response);
</script>

With HMPL, we gain granular control. You can intercept the event, access the FormData, customize headers, control indicators, all within a declarative template structure.

📊 Size comparison

Let's not ignore the size difference.

Alpine.js is incredibly small, and with minimal functionality it stays tiny. Here’s a quick visual:

📦 Alpine.js:

📦 HMPL:

So yes, Alpine lose the size game. But the gap isn’t massive — and if you're building something more interactive or server-driven, the slight size increase might be worth the added flexibility.

Also, in a broader comparison, HMPL still performs surprisingly well:

Of course, the smaller the feature set, the smaller the final JS bundle, but that also means you’ll need to write more imperative logic outside the HTML.

✅ Conclusion

Alpine.js is a great choice for projects that need simple, inline reactivity without the complexity of larger frameworks. But in this article, I wanted to present an alternative.

HMPL offers a more modern, customizable approach to server-driven UI. If your app requires dynamic data handling, advanced request logic, or full fetch control — HMPL might be a better fit.

In the end, it’s all about the right tool for the right job.

Thanks for reading this article ❤️!

What’s your take on this comparison? Let me know in the comments!

Useful links:

🐜 HMPL.js: Small Template Language. Reduce the build size several times 📦

Anthony Max — Fri, 13 Jun 2025 16:09:18 +0000

TL;DR

When you work with modern frameworks, the first question that comes up is the size of the bundle you generate.

Yes, of course not first and foremost, but the client doesn't care how the developers do the project. He wants the site to load quickly!

So, in this article I would like to look at a small template language that will help you make the same application, but with much less effort.

Well, let's see what this project is 🔎

👀 Is there an example of reducing the build size?

We'll take a specific application on Next.js and HMPL.js and see how much it will weigh in the end.

📦 Next.js build:

📦 HMPL.js build:

This build is 10x smaller than the Next.js build. Moreover, we keep the interface in its original form, without losing any advantages (except for indexing by robots).

This is just a regular landing page without any frills. Just a couple of animations in the banner and a countdown for a limited offer.

Also, it would be great if you supported the project with your star! Thanks ❤️!

💎 Star HMPL ★

📊 How does it compare to other modules?

Obviously, it's not entirely fair to take Next.js, since it's a bit different, but nevertheless it's fair, because our goal is to make a site with a good interface, and for this purpose all means are good.

But let's try to compare it with similar modules:

And here too it is clear that the applications from this test are smaller in the result, even if we compare them with Alpine.js, which essentially does the same thing.

🖋 What does the syntax of a template language look like?

The template language provides the following block extension for HTML:

<div class="wrapper">
  {{#request src="/api/my-component.html"}}
    {{#indicator trigger="pending"}}
      <p class="my-indicator">Loading...</p>
    {{/indicator}}
  {{/request}}
</div>

Here, we are describing a certain component (which is not really a component, since it is a helper block), but nevertheless, for general understanding it is perfect. Instead of it (like outerHTML), we load the HTML that comes to us from the server.

⚙️ Try this project

Package Manager: You can install it by typing npm i hmpl-js in the terminal
CDN Method: You can load these libraries directly from a CDN by embedding the following script tags in your HTML:

  <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>

Local Setup: If you prefer offline usage, download the files and host them yourself - functionality remains identical.

✅ Our code is Open Source

So you can take part in it too! We welcome activity and want to make this project better!

GtiHub Repository: https://github.com/hmpl-language/hmpl
Website: https://hmpl-lang.dev

Thank you very much for reading this article! I hope this project will be useful to you! ❤️

💬 What do you think? It will be interesting to know in the comments!

📢We did it...

Anthony Max — Mon, 02 Jun 2025 07:23:29 +0000

Hello everyone! Today is one of the most important days in the history of our project - we are launching on ProductHunt!

Over the course of a year, we created a framework, refined the syntax, added functionality, improved documentation, and much more!

More than 20 contributors helped the project become a little better in code, I would really like not to lose their contribution, but to show everyone how cool it is done. In this article, we will talk about this

Let's get started! 🏎️

⚙️ Preparing for launch

Probably one of the longest sessions. It took me a week to create the pictures and video - this is the basis. But I think it was worth it.

But first you need to come up with a description text, specify a tagline and upload a logo.

You can specify an emoji in the product description, but it is better not to, and to do it only in the attached comment.

Quite trivial fields that are filled in quickly. By the way, sometimes they are not saved, so prepare all the content at once.

🎬 Launch Media

So, about the pictures - this was one of the longest stages. To create something incomprehensible from scratch is not obvious, and it also has to show the product beautifully.

The complexity of our project is that it is not a Software As A Service product. I can't just throw in screenshots from the service and add text. Here I had to think about what would work well.

The video took up most of the time. It's not clear what to do and how to do it.

It seems like the video turned out well. All these transitions, of course, took a long time to make, but I think that this also looks good.

💬 About development

We have been doing this project for a year now and have written many articles on this topic. Every major update leaves its mark, everything is built publicly.

Many people helped the project become a little better, thank you! Some helped with code:

And someone with a comment, a like, a review of the project. I think this is important.

🐈‍⬛ A little bit about ProductHunt

I like the atmosphere that has been built on this platform! Most small projects have received the most necessary thing - feedback on what you are doing.

If you did something wrong, people can politely tell you about it. A bunch of forums on projects, an active community - all this makes this service one of the necessary ones for developers today.

🐜 Our launch

You can support us on ProductHunt🌱:

💎 HMPL Launch

Thank you very much for reading this article❤️!

HMPL.js Forem: HMPL.js

📢 We're opening a list of community projects! You can participate.

🔎 What's the point?

💬 Feedback

🔗 Links

Major module update!

⚙️ vite-plugin-hmpl and hmpl-loader

🌳 hmpl-dom

💬 Feedback

✅ This project is Open Source

New major HMPL version 3.2.0 🕶

🔗 Bind

👀 How is it with HATEOAS?

📢 HMPL v3.1: New major update!

🔏 Improving security

⚙️ Changing arguments for the get function

💬 Feedback

✅ This project is Open Source

📢 HMPL is participating in Hacktoberfest 2025!

👻 About the festival

🌱 Our participation there

👀 What now?

🔗 Useful links

LocalStorage vs SessionStorage vs Cookies: A Complete Guide 🗄️

🗄️ LocalStorage

🕓 SessionStorage

🍪 Cookies

✅ Conclusion

📢 New Docs: How We Revamped Our Documentation with Astro Starlight 🌌

👀 Why did we choose Astro Starlight for the new documentation?

1. 💎 Design

2. 🌊 Freshness

3. Support for old files

📚 New in documentation

⚙️ How can you add this documentation to your project?

✅ Conclusion

🔗 Links:

📢 HMPL-DOM v0.0.1 Released: Write Reactive HTML Without JavaScript

⚙️ Structural modules and the real DOM

🔥 Hype on attributes

👀 What if I need to pass RequestInit?

🔗 Links

💬 Feedback

From 0 To 500 GitHub Stars: Our Year-Long Adventure🔥

📚 History of HMPL.js

👀 What is this project?

🌱 Why do people give stars to a project on GitHub?

❤️ And finally...

I replaced Alpine.js in my app with this alternative 🔥

⚙️ From simple examples

🔍 Built-in limitations

🔗 Complex example

📊 Size comparison

✅ Conclusion

🐜 HMPL.js: Small Template Language. Reduce the build size several times 📦

TL;DR

👀 Is there an example of reducing the build size?

📊 How does it compare to other modules?

🖋 What does the syntax of a template language look like?

⚙️ Try this project

✅ Our code is Open Source

📢We did it...

⚙️ Preparing for launch

🎬 Launch Media

💬 About development

🐈‍⬛ A little bit about ProductHunt

🐜 Our launch

👀 What if I need to pass `RequestInit`?