Skip to content

KEML

KEML — Actions over abstractions.
Enhance HTML with expressive, declarative attributes that connect your frontend directly to your server logic.

npm bundle size Latest Release License Open Issues Open PRs Docs

KEML is a modern HTML extension that adds powerful, declarative attributes to standard markup. With KEML, you define behaviors like form submission, navigation, state transitions, and conditional rendering directly in your HTML — all handled by the server. There's no client-side JavaScript to write, manage, or debug. Just clean, maintainable, server-driven apps.

KEML builds on the core idea that HTML can drive your application's behavior. Inspired by the elegance of HTMX (https://htmx.org), KEML takes that vision further — removing limitations, embracing composability, and keeping everything within your markup.

No selectors. No JavaScript. No surprises.
Just expressive, maintainable, declarative HTML.

Motivation

Being small and fast and configuration/plugin free is not enough, when you are trying to compete with a well established and popular library.

So, why does KEML need to exist?

KEML was born out of the classic 1-to-1 problem of the traditional jQuery-esque web application, that the HTMX api does nothing to address.

Consider the following "idiomatic" HTMX code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
<button
  hx-post="/clicked"
  hx-trigger="click"
  hx-target="#result"
  hx-swap="innerHTML"
>
  Click Me!
</button>

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

Here the button element:

  1. can only react to exactly 1 event ("click")
  2. can only do 1 thing when that event happens (send a request to "/clicked")
  3. cannot delegate the request-sending to some other element/-s
  4. can only render the result into 1 (usually) target element
  5. has to know where that element is on the page, what its "id" and/or "class" attributes are
  6. has to decide for the target element the exact "hx-swap", of which there can only be 1

Out of these limitations arise:

  1. the need for a custom selector syntax built on top of the normal css-selector syntax
  2. the need for selectors in the first place, which you need to learn and understand to use the library effectively
  3. the implicit special handling of certain elements, like title and meta, present in the server response
  4. out of band swaps
  5. response selectors
  6. "hx-preserve"
  7. etc, etc, etc...

All which, are meant to solve real tangible application needs, but in the process of doing that over-complicate things that do not need to be complicated.

How is KEML different?

Consider the following KEML code, that works with the same backend:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<html>

<head>
  <title render="result"></title>
</head>

<body>
  <button
    on:click="handleClick doSomethingElse"
    on:dblclick="handleDoubleClick"
  >
    Click Me!
  </button>

  <button on:click="handleClick">Click Me, maybe?!</button>

  <input
    on="handleClick"
    post="/clicked"
    type="text"
    name="input1"
    result="result"
  >

  <input
    on="handleClick"
    put="/notification"
    type="text"
    name="input2"
  >

  <div
    render="result"
    position="replaceWith"
  ></div>

  <p
    render="result"
    position="append"
  ></p>
</body>

</html>
  1. both buttons initiate the same "handleClick" action on "click"
  2. the first button actually initiates two independent actions on "click", that could both do completely different things
  3. the first button also reacts to the double click event
  4. neither of the buttons needs to know how those actions are being handled, if at all
  5. the two text inputs both handle the "handleClick" action, but send completely different requests
  6. the first input gives the server response a render-able name "result"
  7. neither of the inputs knows anything about the rendering, whether or not anything is even going to be rendered at all, where and how
  8. the div, p and title elements render the same server response differently
  9. the div will be completely replaced with the response
  10. the p will append the response after its last child
  11. the title will replace all of its children with the response
  12. there is nothing special about the title element at all
  13. there's no need for ids, classes or selectors and the location of each element in the document is completely unimportant

None of the problems that HTMX tries to solve with the complications listed above even exist in this paradigm!