Mador is an 855-byte reactive DOM runtime that skips the framework

A developer publishing as marsbos has released Mador, a minimal open-source runtime that adds reactive state to plain HTML pages. The project reached the Hacker News front page through a Show HN post, where it is billed as an 80-line Proxy state tuple, and its GitHub README reports that the entire library minifies to roughly 855 bytes.

What Mador does

Mador is aimed at pages that already have their HTML and JavaScript in place but could use a little state-driven updating. Rather than rendering anything itself, it connects a JavaScript state object to elements that already exist in the document. The library ships as a native ES module, is available through npm or directly from a CDN, and according to the README needs neither a global runtime nor a build step.

The read and write API

Calling mador() with an initial state object returns a pair of functions:

js const [read, write] = mador({ count: 1 });

The read function builds a binding out of three parts: a CSS selector that picks the elements to update, an update callback that receives each matched element along with a derived value, and a selector function that pulls the relevant slice of state. In an example from the README, a .counter element is tied to state.count, and the callback sets the element's text content from that value.

State changes go through write, which hands the state object to a mutator function, such as one that increments count. The README is explicit that nothing sits on top of this mechanism: the library deliberately rules out components, template syntax, and a virtual DOM.

Dependency tracking and batching

Under the hood, Mador records which state properties a binding actually reads and reruns that binding only when one of those dependencies changes, so writing to an unrelated part of the state leaves the binding alone. Writes are also batched: several mutations performed inside a single write call are processed together instead of each triggering its own pass over the bindings.

Cleanup tied to element lifetime

Bindings are associated with the markup they update. When the elements a binding selects disappear from the document, Mador can tear down the reactive runner behind that binding. Because the library has no components in the first place, the README argues, there is no component lifecycle for a developer to manage either — reactivity lives and dies with the DOM it touches.

Why it matters

Mador occupies the gap between two familiar extremes: hand-rolled event listeners that drift out of sync as a page grows, and adopting a full framework with components, re-rendering, and a toolchain for what may amount to a handful of dynamic values. At under a kilobyte, it can be dropped into a static or server-rendered page from a CDN without changing how that page is built or served. The trade-off is equally narrow — developers keep full ownership of the markup and the update logic, and the project offers nothing beyond state, bindings, and cleanup. As a brand-new release, its durability in production is unproven, but the code is MIT-licensed and publicly available on GitHub under marsbos/mador, which makes it easy to audit for anyone whose use case fits its deliberately small footprint.