This looks best for sprinkling reactivity onto plain pages, not for apps that need a lot of structure. The tradeoff is sensible: less machinery and less indirection, but more importance on being explicit about state boundaries and selector driven updates.

Mador
Mador is a very small reactive DOM runtime that enables reactive state management and bindings to existing DOM elements without using a framework. It is a native ES module distributed via npm or CDN. It allows reactive bindings to DOM elements with minimal overhead, no virtual DOM, and no components, ideal for adding reactivity to existing pages.
Ratings & Reviews
Write a reviewInformation
Around the Web
Hey HN! I wanted to see how far you can push modern JavaScript Proxies without all the heavy overhead of a traditional framework. The result is Mador: a tiny ~80-line reactive state tuple ([r, w]) that lets you make any DOM element reactive using a simple CSS selector, automated dependency tracking, and batched microtasks. No build steps required—just drop it in. I built this over the weekend just to experiment with clean, zero-dependency reactivity. Would love to hear your thoughts or see where you'd run into limits with something like this!
bosmarcel · Imported from Show HN
Proposed variant optimised for human readaiblity... ```js import mador from "mador"; const [read, write] = mador({ count: 1 }); read(".counter", ctx => ctx.el.textContent = ctx.count); write(".increment", "click", ctx => ctx.count++); write(ctx => ctx.count = 0); ``` ## Read Dependencies are detected automatically when the read function is run during initiation. ```js read(".counter", ctx => ctx.el.textContent = `Count: ${ctx.count}`); ``` ## Write Immediate: ```js write(ctx => ctx.count++); ``` Event-triggered: ```js write(".increment", "click", ctx => ctx.count++); ``` Event writes expose `ctx.el` and `ctx.event`.
moostee · Imported from Show HN
The core idiom I've used for years is deliberately tiny: fully encapsulated custom Web Components that simply re-render when matching an attribute and `window.state` changes. Data model is simply: window.state = new Proxy({}, { set(target, key, value) { target[key] = value document.querySelectorAll(`[data="${key}"]`) .forEach(el => el.render?.()) return true } }) handles reactivity.. https://github.com/digplan/vanilla-light
dpweb · Imported from Show HN
There are many standalone plug-n-play implementations of the signal primitive in JS. To name a few: preact/signals, vue reactivity, etc, there's even a TC39 proposal for a lang feature. Is this meant to stand out by doing things differently or reinvent them?
bedroom_jabroni · Imported from Show HN
> Hey HN! I wanted to see how far you can push modern JavaScript Proxies without all the heavy overhead of a traditional framework. The result is Mador: a tiny ~80-line reactive state tuple ([r, w]) that lets you make any DOM element reactive using a simple CSS selector, automated dependency tracking, and batched microtasks. No build steps required—just drop it in. I built this over the weekend just to experiment with clean, zero-dependency reactivity. Would love to hear your thoughts or see where you'd run into limits with something like this! Unsure why this comment from the author was flagged/dead but it certainly doesn’t seem to run afoul of HN guidelines.
hamburglar · Imported from Show HN