4 ms·

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 pro

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?

bosmarcel 1mo 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
- bedroom_jabroni 1mo 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.
  - bosmarcel 1mo 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!
    - bedroom_jabroni 1mo 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".
  - kevinfiol 1mo 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.
    - bosmarcel 1mo ago
      Great post/reply, thanks a lot
    - bedroom_jabroni 1mo 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.
      - kevinfiol 1mo ago
        Fair, although I'm aware of preact/signals-core, what are React/Vue's standalone reactive libraries?
        phatskat 1mo 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/src https://github.com/vuejs/core/tree/main/packages/reactivity/...
- afavour 1mo ago
  First time I’ve seen Preact described as a “big solution”!
nxobject 1mo ago
(Just for (my) reference, the TC39 proposal is here: https://github.com/tc39/proposal-signals https://github.com/tc39/proposal-signals)
royal_ts 1mo 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.

bosmarcel 1mo 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

bedroom_jabroni 1mo 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.
- bosmarcel 1mo 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!
  - bedroom_jabroni 1mo 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".
- kevinfiol 1mo 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.
  - bosmarcel 1mo ago
    Great post/reply, thanks a lot
  - bedroom_jabroni 1mo 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.
    - kevinfiol 1mo ago
      Fair, although I'm aware of preact/signals-core, what are React/Vue's standalone reactive libraries?
      - phatskat 1mo 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/src https://github.com/vuejs/core/tree/main/packages/reactivity/...
afavour 1mo ago
First time I’ve seen Preact described as a “big solution”!

nxobject 1mo ago

(Just for (my) reference, the TC39 proposal is here: https://github.com/tc39/proposal-signals https://github.com/tc39/proposal-signals)

royal_ts 1mo 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.