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!
Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
21–30 of 37 posts
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#22I’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.
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.
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#23The 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
> 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.
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#24There 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?
(Just for (my) reference, the TC39 proposal is here:
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#25Earlier quoted context omitted.
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. 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').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++; });
});
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#26Earlier 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…
Great post/reply, thanks a lot
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#27The 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. Thi…
https://github.com/tc39/proposal-module-expressions will fix the latter.
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#28[flagged]
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#29The 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/vanill…
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.
Re: Show HN: Mador – Make any DOM reactive with a tiny 80-line Proxy state tuple
#30The 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. Thi…
> And you cannot distribute an app as as HTML file.
console.log('Hello World!')
export const a = 5
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.