Discover

Mador

Make Any DOM Reactive with a tiny 80-line Proxy state tuple
7 ratings4.04
Saves101
CategoryDeveloper Tools
PlatformWeb
PricingFree

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 review
4.04

7 reviews

Product
3.54
Design & Polish
4.54
Performance
4.04
9/14/2026

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.

Information

CategoryDeveloper Tools
PlatformsWeb
PricingFree
AccountNot confirmed
ListedSeptember 2026
Report a problem

Around the Web

Show HN101 source points · 35 comments

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