Mador binds DOM elements to reactive state in an 855-byte runtime

A Show HN submission introduces Mador, a minimal reactive DOM-binding runtime shipped as a native ES module and installable via npm or a CDN script tag. Mador exposes a state object as a read/write tuple created with a single function call: calling mador() with an initial state object returns a read function for wiring DOM updates and a write function for changing state. A binding is created by calling read with three arguments: a CSS selector that picks the elements to update, an update callback that receives each matched element plus a value, and a second function that reads the piece of state the binding depends on. Mador tracks which state properties a binding actually reads and only reruns that binding when those specific properties change, rather than re-rendering more broadly. State changes go through write, and multiple state changes made inside the same write call are batched and processed together. Bindings are tied to the DOM elements they update: when those elements are removed from the page, Mador can drop the corresponding reactive runner, so there is no separate component lifecycle to manage by hand. There are deliberately no components, templates or virtual DOM; Mador works directly on the DOM markup a page already has. According to the project description, the runtime is currently around 855 bytes minified, no global runtime object is needed, and no build step is required to use it. The project is released under the MIT license.

Key facts

Mador creates reactive state with a single call that returns a read function (to bind DOM elements) and a write function (to change state).
A binding is read(selector, update, read): the selector picks elements, update applies the new value to each, and read selects the state slice the binding tracks.
Mador only reruns a binding when the specific state properties it reads have changed, and batches multiple state changes made in one write call.
The minified runtime is around 855 bytes; it ships as an ES module usable via npm or a CDN URL, with no build step and no global runtime object required.
Mador removes a binding's reactive runner once its matching DOM elements are gone, so there is no separate component lifecycle to manage.

Why it matters

Most reactive UI tooling asks a page to adopt a component model, a virtual DOM diffing layer and a build pipeline. Mador targets the opposite case: a page that already has working HTML and vanilla JavaScript and needs only a thin layer of reactivity bolted onto elements that already exist. Its selling point is size and simplicity, not feature breadth: an 855-byte minified runtime with three moving parts (a selector, an update function, and a state-reading function) that a developer can hold in their head without documentation.

Who it affects

Front-end developers working on small sites, prototypes, widgets or legacy pages who want reactive data binding without pulling in React, Vue or a similar framework and its build tooling. It is aimed squarely at people who, in the project's own framing, do not need or want a framework, rather than at teams building large component-driven applications.

How to use it

Mador is installed as a native ES module, either from npm or directly from a CDN (the README shows importing it from jsdelivr) with no build step required. Calling mador(initialState) returns a [read, write] tuple. read(selector, update, read) wires a CSS selector to an update callback and a function that selects which piece of state the binding depends on; write((state) => { ... }) mutates state, and changes made within one write call are batched together. The project is MIT licensed, so it is free to use and modify without royalty.

How solid is it

The claims in the retelling come directly from Mador's own project description and code examples: the dependency-tracking behavior, the batching of writes, and the automatic cleanup of bindings when their DOM elements disappear are all stated by the author, not independently verified by outside benchmarks. The submission had drawn 85 points and 27 comments on Hacker News at the time of writing, indicating community interest, but no adoption figures, browser-compatibility statement or comparison to other libraries appears in the source material.

Risks and caveats

As a very young, single-maintainer project with no stated version history or release notes in the text, Mador carries the usual risks of small open-source libraries: unclear long-term maintenance, no described migration path, and no independent benchmarking of its performance or dependency-tracking claims. The source does not name an author, maintainer or organization behind the project, nor does it compare Mador's capabilities or limitations against established alternatives like Alpine.js or Vue's reactivity system.

“There are no components, templates or virtual DOM.”

— Mador project description