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

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

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:

 x-data="formComponent()" id="wrapper">
   @submit.prevent="submit">
     class="form-example">
       for="login">Login: 
       type="text" name="login" id="login" x-model="form.login" required />

       for="password">Password: 
       type="password" name="password" id="password" x-model="form.password" required />