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.

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

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.

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.

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.

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

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

Great post/reply, thanks a lot

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!

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

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

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

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

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

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.

Hahaha! Exactly

Thanx a lot!

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!

Hi HN! Creator of Flynt.js here.

I built Flynt.js to solve a common pain point in Multi-Page Application (MPA) setups like Magento/Hyvä, Laravel, and Rails: managing complex UI state without polluting HTML templates with heavy inline JS logic or dragging in massive framework bundles.

Key features: - Zero-build & Lightweight: ~150 lines of plain JS, zero dependencies. - Clean HTML (Presenter Pattern): Decouples logic into JS Presenters instead of heavy inline template attributes. - 100% Strict CSP Compliant: Never uses eval() or new Function(). - Native-friendly: Built-in automatic request aborting (no race conditions) and key-based DOM diffing for lists.

Currently working on a form extension for native HTML5 validation handling.

Would love to hear your feedback, thoughts, or suggestions!

https://github.com/marsbos/flynt.js

Hi everyone!

Thanks for the interest in fluent-state.

Just a quick note: for easy installation and trying out the demo, check out these links:

NPM: https://www.npmjs.com/package/fluent-state

Demo: https://stackblitz.com/edit/vitejs-vite-uh4kyzkf?file=src%2F...

The GitHub repo is still available here for source and issues: https://github.com/marsbos/fluent-state

Happy coding!