Reactive HTML Without JavaScript Frameworks

The binding between trees and DOM nodes uses functional closures. When the compiler generates code like $.L($.pV(a),'name'), it creates something equivalent to:

function() {
  var node = document.createTextNode("");
  viewstate.subscribe({name: function(name) {
    node.nodeValue = name;
  }});
  return node;
}

The closure captures the DOM node directly. When the tree value changes, the subscriber fires and updates that specific node. No virtual DOM diffing. No reconciliation pass. No component re-renders. The information flow goes from tree change to DOM node with zero intermediate steps.

This is the historical origin of RxHTML. I was building products with both vanilla JS and React, and the repetitive work of binding data changes to DOM changes was maddening. The closure-based approach is not novel -- it is how every spreadsheet works -- but applying it to HTML templating eliminates the entire category of problems that React, Vue, and Angular exist to solve.

How Lists Work

When a field is a list, the $.IT function handles the DOM:

$.IT(container, treeNode, 'lines', false, function(itemNode) {
  var div = $.E('div');
  div.append($.L(itemNode, 'who'));
  div.append($.L(itemNode, 'what'));
  return div;
});

The function argument is the instruction for how to build a DOM element for a new list item. When items appear, the function is called and the DOM element is inserted. When items disappear, their DOM element is removed. When ordering changes, DOM elements are reordered. All of this is driven by the JSON diffs arriving from the server -- the server sends {"@o": [...]} ordering instructions, and the list manager translates them directly into DOM operations.

Forms, Actions, and the Read-Write Loop

Forms in RxHTML send messages directly to Adama channels:

<form rx:action="send:say">
  <input type="text" name="what" />
  <button type="submit">Say</button>
</form>

The compiler generates $.aSD(form, connection, 'say') which hooks the form's submit event to collect all input values into a JSON object and send it to the say channel on the current connection. The channel handler runs on the server, mutates document state, which produces a JSON diff, which flows back over the WebSocket, which updates the data tree, which fires the closures, which updates the DOM.

That entire round-trip -- form submit to visible UI update -- happens with zero JavaScript written by the developer. The feedback loop is: user interacts -> view state or server message -> tree updates -> DOM updates.

For client-side interactivity, RxHTML has a command language on events:

<button rx:click="toggle:show_details">Toggle Details</button>
<button rx:click="set:tab='settings'">Settings Tab</button>
<button rx:click="inc:counter">+1</button>

These modify view state directly. Combined with rx:if for conditional rendering and rx:sync for input-to-view-state binding, you can build surprisingly complex client-side interactions without writing JavaScript.

What This Cannot Do

RxHTML is not a general-purpose JavaScript replacement. It specifically solves the problem of building data-driven UIs connected to a reactive backend. Here is what it does not handle:

Complex client-side logic. If you need sophisticated local computations, animations, or canvas rendering, RxHTML's command language (toggle, set, inc, dec) is insufficient. The escape hatch is Web Components -- I wrapped CodeMirror 6 into a Web Component and it works fine inside RxHTML templates.

SEO for dynamic content. RxHTML's client-side pages produce a single-page application. Search engines that do not execute JavaScript will not see your dynamic content. For content that needs SEO, RxHTML provides <server-page> elements that render on the server and return complete HTML. Server pages support authentication and remote data fetching via <remote-inline>, but they are not reactive -- they are traditional request-response pages. For applications behind a login, SEO is irrelevant.

Offline-first applications. RxHTML depends on a WebSocket connection to the Adama backend. If the connection drops, the UI shows a disconnected state. There is no local persistence or offline queue.

Third-party JavaScript integration. If your workflow depends on npm packages for charting, rich text editing, or other complex widgets, you need to wrap them as Web Components. This works but requires JavaScript knowledge for the wrapper.

The tradeoff is clear: RxHTML gives you zero-framework reactive UIs at the cost of being coupled to the Adama backend and limited to what declarative templates can express. For the 80% of application UI that is "show data, accept input, show updated data," it is dramatically simpler than React. For the 20% that requires complex client-side behavior, you use Web Components or write vanilla JS.

I am currently building the entire Adama web portal with RxHTML, and it works well. I spend my time on the domain problem rather than framework glue. I use Tailwind for styling, RxHTML for data binding, and Web Components for the rare cases where I need real client-side logic. The result is fast, stable, and has zero transitive npm dependencies.