HTMX vs KEML: The Loading State Example That Shows the Difference

Eugene Kuzmenko — Tue, 14 Apr 2026 09:11:32 +0000

A while ago, I wrote about KEML.

It didn’t land the way I wanted it to.

Not because the idea was bad — but because the examples were.
I showed things that tools like HTMX already do very well:
send a request on click, render a response, repeat.

And if that’s all you see, then yeah — KEML just looks like different syntax.

This time, I want to show something that actually feels different.

The smallest interesting example: loading state

Let’s start with a very real UI problem:

Show a loading indicator while a request is in progress.

The HTMX way

<button 
  hx-get="/data"
  hx-target="#result"
  hx-indicator="#spinner"
>
  Load Data
</button>

<div id="spinner" class="htmx-indicator">
  Loading...
</div>

<div id="result"></div>

.htmx-indicator {
  display: none;
}

.htmx-request .htmx-indicator,
.htmx-request.htmx-indicator {
  display: block;
}

This works well. It’s concise. It’s idiomatic.

But notice what’s happening:

the button references the spinner (#spinner)
the button references the result (#result)
loading is a special concept (hx-indicator)
visibility is controlled indirectly via CSS

Nothing here is wrong. But everything is connected.

The same thing in KEML

<button
  on:click="send"
  on="send"
  get="/data"
  result="response"
  if:loading="spinner"
>
  Load Data
</button>

<div if="spinner" style="display:none;" x-style="display:block;">
  Loading...
</div>

<div render="response"></div>

If this idea feels interesting, you can explore the details here:

https://thealjey.github.io/keml

What just changed?

At first glance, not much.

But the mental model is completely different.

1. No element references

The button does not know:

where the response will render
where the loading indicator lives
whether either of them even exists

And the other elements don’t know about the button.

They just react.

One practical benefit of this approach is that these connections are no longer just strings.

Because actions are named identifiers, they can be statically analyzed and
tooled:

Go to definition / references
detection of undefined or unused actions
safe renaming across the codebase

This makes relationships between elements explicit and verifiable, rather than
relying on runtime selector matching.

2. Everything is explicit

There’s no hidden behavior:

on:click="send" → produces an action
on="send" → consumes it and sends a request
result="response" → produces another action
render="response" → consumes it
if:loading="spinner" → produces yet another action
if="spinner" → consumes it

No special cases. No magic elements. No CSS side channels.

3. “Loading” is not a feature

There is no such thing as a “loading indicator” in KEML.

There is only state.

State is declared using the pattern:

if:<condition>="name1 name2 ..."

For example:

if:loading="spinner"

This simply declares a state action called spinner that is activated during a loading request.

And once state exists, anything can react to it:

<div if="spinner" x-style="display:block;">

This same pattern applies everywhere:

if:error="..." → error state
if:invalid="..." → validation state
if:value="..." → input state
if:intersects="..." → visibility state

But none of these are special cases.

They are all the same mechanism:

if:<condition> defines state, and if consumes it.

The if attribute has nothing to do with visibility (or loading) specifically.

It allows elements to declaratively configure any attribute value in the DOM
based on state.

When a state is ON, attributes prefixed with x- temporarily override their
base value.

When the state is OFF, the original attribute values are restored.

The important difference

The easiest way to describe it is this:

KEML removes the need to reference other elements entirely.

In HTMX, you wire elements together:

“send this request”
“put the result there”
“show that spinner”

In KEML, you name things:

“this action happened”
“this result exists”
“this state is active”

And the DOM reacts.

Why this matters (even for small things)

For a tiny example like this, both approaches are fine.

But as things grow:

more triggers
more UI states
more places that react

Referencing elements starts to spread knowledge across your markup:

IDs
selectors
coupling between unrelated parts

KEML doesn’t prevent that.

It just… doesn’t require it.

One small gotcha

Actions are global.

So naming matters.

on:click="loadData"

If multiple elements use loadData, they will all react.

This is intentional — but something to be aware of.

Final thought

KEML isn’t trying to replace HTMX.

They’re aiming at the same idea:

server-driven, HTML-first applications

KEML just takes a different route:

instead of connecting elements, it lets them react to signals.

If this made you pause for even a second — that’s enough.

Give it 5 minutes.

That’s all it really needs.

If you want to try it in a real project, it takes very little setup:

Docs → https://thealjey.github.io/keml
npm → https://www.npmjs.com/package/keml
GitHub → https://github.com/thealjey/keml

Keml: Empowering UI Development, One Developer at a Time

Eugene Kuzmenko — Mon, 27 May 2024 20:41:31 +0000

Hey Fellow Developers,

I'm thrilled to introduce you to Keml – a small yet mighty alternative to HTMX that's poised to change the game in UI development. And the best part? It's crafted and maintained by just one person (that's me!).

Here's why Keml deserves a spot in your toolkit:

1. Versatile Integration, Zero Hassle 🛠️

With Keml, you're not tied down to a specific server-side stack. Whether you're rocking Node.js, PHP, Java, Python, or C#, Keml plays nice with them all. And guess what? Your server doesn't even need to know it's rendering Keml syntax – it's just standard HTML with a dash of extra custom attributes. Seamless integration, zero headaches.

2. Simplify UI Building with HTML-Extended Syntax 🏗️

Say goodbye to cumbersome JavaScript coding! Keml's magic lies in its extended HTML syntax, designed to make UI development a breeze. Build highly interactive user interfaces directly within your HTML markup, no complicated scripts required.

3. Performance, Flexibility, Simplicity – All in One 🚀

Keml isn't just about features; it's about delivering lightning-fast user experiences without the complexity. Think of it as your trusty sidekick, prioritizing performance, flexibility, and above all, simplicity. And since it's a one-person endeavor, your feedback and contributions carry extra weight in shaping Keml's future.

4. Early Stage Development, Honest Disclaimer 🚧

Let's keep it real – Keml is still in its early stages of development. Bugs might pop up here and there, but with your help, we'll squash them in no time. Your input matters more than ever as we refine Keml and pave the way for smoother UI development.

5. Dive into Keml Today 🎨

Ready to experience Keml firsthand? It's as easy as:

<!-- "install" the library -->
<script src="https://unpkg.com/keml"></script>

<!-- initiate an action -->
<button on:click="updateCounter">
  Click me!
</button>

<!-- send a post request on action -->
<div
  on="updateCounter"
  post="/increment"
  result="counterValue"
></div>

<!-- render responses -->
<p>
  Here we have the value of counter:
  <span render="counterValue"></span>.
  And here it is again, but smaller:
  <small render="counterValue"></small> ;)
</p>

Join me on this journey to simplify UI development, one line of code at a time. Have questions, feedback, or just want to say hi? Connect with me on GitHub. I'm all ears!

Embrace simplicity with Keml – your partner in effortless UI magic! ✨

This article was written with the help of ChatGPT. But, after reading and re-reading it a few dozen times, I realize that it perfectly and concisely formulates my own thoughts better than I, probably, ever could by myself without a great number of revisions and tweaks.

Cheers,
https://github.com/thealjey/keml

Forem: Eugene Kuzmenko