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?
Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
31–37 of 37 posts
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#32Earlier quoted context omitted.
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. Th…
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').addE…
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#33Earlier quoted context omitted.
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. Th…
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…
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#34Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#35Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#36Earlier quoted context omitted.
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').addE…
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.
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#37Earlier quoted context omitted.
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?
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/...