HTM/A Server-side reactivity, in four kilobytes Four and a half kilobytes, and no npm in sight

Before the argument, the facts

In development, and the source is not yet published, so every figure here rests on trust until it is. What is measured is measured: 4.5 kilobytes compressed with Brotli for the entire framework, 1,276 lines of source, no dependencies at all, and 126 tests passing. The comparison further down names the frameworks it compares against and their sizes, which is the only sort of comparison worth printing.

The argument, in seven steps

• OneThe markup is the programmeAttributes on ordinary elements. No JSX, nothing to compile.
• TwoThe server sends HTMLTwo steps where the usual arrangement takes five.
• ThreeThe flow is a lineEvent up, HTML down. No state to synchronise on both sides.
• FourOne attribute changes the transportPolling, then Server-Sent Events, then WebSocket. No refactor.
• FiveAccessible because it is ordinaryA real button before a div with a role bolted on.
• SixWhat it weighs4.5 KB against a typical bundle a hundred times that.
• SevenTwo ways to run the serverA runtime that needs no Rust, or a macro that is typed at compile time.

Then, for reference

• NumbersThe comparison in fullFive frameworks, their weights, and what that costs on a phone.
• EdgesWhere it stopsThe applications this is the wrong answer for, said plainly.

You already know where the button is

The behaviour of a page is written where the page is: on the elements themselves, as attributes, in a file a browser can open without help. There is no separate component language, no transform between what you wrote and what runs, and consequently nothing to install before the first line works.

    <htma-endpoint url="/counter" io="websocket">
      <h1>Count: <htma-content name="value">0</htma-content></h1>
      <button htma-bind="increment">+</button>
    </htma-endpoint>
        

That is a working counter over a live socket, and it is also just HTML. The element says where to talk and how; htma-content marks the part that will be replaced; htma-bind says which event goes back. A colleague who has never seen the framework can read it, which is a property most of the alternatives gave up somewhere around the second build tool.

The rest of the surface is the same shape: htma-action, htma-link, htma-modal, htma-sortable. Forms, tabs, modals, drag and drop, toasts and infinite scroll are all in the four and a half kilobytes, and none of them arrives as a separate package.

Which raises the obvious question: if the browser is not assembling the page, who is?

Event up, HTML down, and no circle to debug

The pattern has a name in the project, EASL, which stands for event, actor, stream and lined. The first three are the parts and the fourth is the point.

    Event   the reader clicks, types, scrolls
    Actor   the server takes it and updates its own state
    Stream  the server sends back fragments of HTML
    Lined   in one direction, with nothing pointing back
        

A single-page application holds state on both sides of the wire and spends a good part of its life keeping the two copies honest. State changes cause renders, renders cause effects, effects change state, and somewhere in that circle sits the afternoon you lost to working out why something rendered twice. There is no second copy here, so there is no synchronisation, no hydration mismatch, and no question of which side was right.

A line is easy to reason about. Is it also easy to make fast?

A real button, before a div wearing a role

Accessibility here is mostly a consequence rather than a feature. When behaviour is an attribute on a real <button>, the button is already focusable, already announces itself, already responds to the space bar and already appears in the tab order. None of that had to be reimplemented, so none of it can be reimplemented incorrectly.

The project's own rule is native elements before ARIA: reach for the element that already means the thing, and add attributes only where the platform has no element for it. WCAG 2.2 at level AA is the target, and the parts that can be arranged automatically are arranged automatically rather than left as an exercise.

This is the quiet advantage of not rebuilding the document. A framework that constructs its own widgets inherits the whole of accessibility as homework; one that decorates the browser's widgets inherits it as behaviour.

So what does the whole of that weigh?

One needs no Rust at all, the other is typed at compile time

The client half is the same either way. The server half comes in two shapes, and which one suits depends on what you are prepared to compile.

An actor is a single file that holds one endpoint's behaviour, and it is worth seeing whole, because the whole of it is short:

    <htma-actor name="Counter">
      {% let value: i32 = 0 %}

      <htma-template>
        <h1></h1>
        <button htma-action="decrement">−</button>
        <button htma-action="increment">+</button>
      </htma-template>

      {% action increment sync %} {% value += 1 %} {% endaction %}
      {% action decrement sync %} {% value -= 1 %} {% endaction %}
    </htma-actor>
        

State, markup and the actions that change it, in one file and in front of you. The state is typed, i32 rather than whatever arrives, and under the compile-time macro that type is checked before anything runs. Each actor keeps its own state and receives messages; nothing is shared and mutable across them, which is the arrangement that removes a whole family of question about who wrote what last.

Keeping all three in one file rather than spread across a route table, a controller and a template is the same instinct as the rest of this: the thing you are working on should be in front of you.

Five frameworks, and what they weigh

Svelte belongs in that list and resists a single figure: it compiles away, so its runtime is around two kilobytes and the output grows with the application rather than sitting at a fixed size. Comparing it by bundle alone would flatter one of us and it is not obvious which.

What the weight buys on a phone: under a second to interactive on a three-G connection against three to eight, and under two megabytes of memory against ten to fifty. Those are the project's own figures and they are the reason any of this matters, because the reader in Lagos or Mumbai on a slow connection is the one who leaves.