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.

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!