Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple

Posted by bosmarcel 1 day ago

Counter99Comment34OpenOriginal

Comments

Comment by codedokode 1 day ago

The syntax looks a bit too verbose for me. And function names like "read" and "write" are confusing too, given that "read" function isn't made for reading values. Cannot we use a single function for binding, like this (and name it "bind")?

    let counter = proxy({ count: 0 });
    bind('.counter', (el) => el.textContent = counter.count);
    counter.count++; // Queues DOM update
Also,

> Mador is distributed as an ES module.

This means it cannot be used on a page opened from disk, and the user needs to set up a HTTP server which is time-consuming and distracting. And you cannot distribute an app as as HTML file.

Comment by inbx0 1 day ago

> And you cannot distribute an app as as HTML file.

  <script type="module">
    console.log('Hello World!')
    export const a = 5
  </script>
Inline module scripts work fine in HTML. You can't import this, but if you'd anyway need to do some "building" (at least doing some string concatenation as a build script) to get any JS baked into the HTML, so why not just concat the library and your own code to one module script in the HTML. Works fine.

I think it's good that folks are starting to end distributing prebuilt code in every possible format that somebody could ask for. Waste of disk space for most people.

ESM is how it's done now. If you don't like it, build it yourself to some other format.

Comment by pwdisswordfishq 1 day ago

https://github.com/tc39/proposal-module-expressions will fix the latter.

Comment by bedroom_jabroni 1 day ago

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?

Comment by nxobject 1 day ago

(Just for (my) reference, the TC39 proposal is here:

https://github.com/tc39/proposal-signals)

Comment by royal_ts 1 day ago

The TC39 proposal seems pretty much dead :(; it doesn't look like much is happening. If I understand it correctly, it's really just about agreeing on a protocol, and it's ultimately up to frameworks to implement it, there isn't anything (yet?) that can run directly in JavaScript.

Comment by bosmarcel 1 day ago

Honestly, mostly for the fun of building it and seeing how small and simple I could make it. While big solutions like Preact or Vue are great, sometimes you just want a tiny zero-dependency script without the overhead. And it turned out to be quite nice as I may say so

Comment by bedroom_jabroni 1 day ago

preact/signals-core has 0 dependencies, your project could also benefit from mentioning what primitive is being implemented for the reader's information. The size difference is negligible. The readme creates a false dilemma where there's either Mador or "having to use a framework" but it hasn't been the case for ages - as I mentioned above the major frameworks have decoupled versions of their reactivity available. This makes the other reply where "the frontend community deserves tools like this" sound weird because it ignores the great tools that have been available for a while.

Good learning experience but a very weird presentation.

Comment by kevinfiol 1 day ago

It's not that weird of a presentation, just different ergonomics for the same problem.

preact/signals-core is great, but since HTML elements have no way to subscribe to signals, you have to handle that yourself:

  import { signal, effect } from "@preact/signals-core";

  const $ = (s) => document.querySelector(s);

  const counter = signal(0);

  effect(() => {
    $('.counter').textContent = counter.value;
  });

  $('.increment').addEventListener('click', () => {
    counter.value += 1;  
  });

  vs mador:

  import mador from "https://cdn.jsdelivr.net/npm/@marsbos/mador@latest/dist/mador.js";

  const $ = (s) => document.querySelector(s);

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

  read(".counter", (el, count) => {
    el.textContent = count;
  },
    (state) => state.count,
  );

  $('.increment').addEventListener('click', () => {
    write((state) => { state.count++; });
  });
Anyways, I love projects like these that try to make working with the web easier with minimal tools.

Comment by bedroom_jabroni 1 day ago

I wasn't referring to the ergonomics - the weirdness was from the way it was worded like "Here's one trick Big Framework doesn't want YOU to know" as if React, Vue and such were gatekeeping their reactivity while they're actively maintaining and sharing standalone versions of it.

Comment by kevinfiol 19 hours ago

Fair, although I'm aware of preact/signals-core, what are React/Vue's standalone reactive libraries?

Comment by phatskat 13 hours ago

You're looking for `@vue/reactivity`[1] - looks like it provides ref, computed, watch, and some internals.

Honestly, this seems pretty nifty. Most projects I'd do today would likely have more value in Vue as a whole, and it's nice to see these kinds of things exposed and standalone bits

[1] https://github.com/vuejs/core/tree/main/packages/reactivity/...

Comment by bosmarcel 1 day ago

Great post/reply, thanks a lot

Comment by bosmarcel 1 day ago

That's a fair distinction, but I think they solve different problems. Signals are great, but they usually require managing primitives individually and don't map directly to deep, nested JS objects the same way. Mador is specifically about dropping in a plain, nested object and working with it like normal JS without .value "boilerplate". Appreciate the feedback on the README phrasing though—I'll tweak it so it doesn't sound like a false dilemma!

Comment by bedroom_jabroni 1 day ago

The .value comparison is not fair because it's a single value vs an object property. A better comparison would be against something like Vue's reactive() where it doesn't require you to add this "boilerplate".

Comment by afavour 1 day ago

First time I’ve seen Preact described as a “big solution”!

Comment by moostee 1 day ago

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`.

Comment by bosmarcel 1 day ago

O yes, thanks, appreciate it! I'm tired now, but i will find the time tomorrow to make it more readable!

Comment by afavour 1 day ago

I’m curious to know what performance looks like. In the recesses of my memory is the belief that proxies are not good for performance but I have no idea if that’s well founded (or maybe once was but isn’t any more).

It’s a very smart idea though, I like it.

Comment by codedokode 1 day ago

It depends on count of variables and dependencies. The much worse problem with proxies is that they can be confused with raw values, for example, you can add a proxy into a Set, and then check for existence of a raw value. Or confuse raw value and proxy in dictionary's keys.

Comment by abosalehworld 1 day ago

I love the minimalist approach here. Using Proxies for state management without the heavy overhead of large frameworks is really elegant. Keeping it under 80 lines is impressive. Great work!

Comment by PoignardAzur 1 day ago

Are reactive updates based on deep equality or reference equality?

Comment by bosmarcel 1 day ago

It is based on ref. equality, so assignment through '=' will trigger an "effect".

Comment by DylanMerigaud 1 day ago

Clean launch, good luck!

Comment by bosmarcel 1 day ago

Thanx a lot!

Comment by ahmedhossamdev 1 day ago

Great work!

Comment by bosmarcel 1 day ago

Thanks, I really appreciate it! Hope others will feel the same. The frontend community needs and deserves simple tools:)

Comment by antonvs 1 day ago

This makes me think of a version of that comic where in the last pane, you get thrown out the window for suggesting such a sensible thing.

Comment by bosmarcel 1 day ago

Hahaha! Exactly

Comment by carlailab2025 21 hours ago

its a good way to standardize

Comment by bosmarcel 1 day ago

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!

Comment by hamburglar 1 day ago

> 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.

Comment by favori995749721 1 day ago

[flagged]

Comment by boldaxolotl 1 day ago

[dead]

Comment by dpweb 1 day ago

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

Comment by bosmarcel 1 day ago

Looks nice!

Imho, custom elements are great, but very limited in a way that they almost always require knowledge of the domain.

Perhaps I can figure out a way to combine mador.js & custom elements.