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?
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.
I’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 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.
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!
The 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.
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.
<script type="module">
console.log('Hello World!')
export const a = 5
</script>
Inline module scripts work fine in HTML.
You can't import this, but if you'd anyway need to do some "building" (at least doing some string concatenation as a build script) to get any JS baked into the HTML, so why not just concat the library and your own code to one module script in the HTML.
Works fine.
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.
22 comments
[ 37.2 ms ] story [ 171 ms ] thread```js import mador from "mador"; const [read, write] = mador({ count: 1 }); read(".counter", ctx => ctx.el.textContent = ctx.count); write(".increment", "click", ctx => ctx.count++); write(ctx => ctx.count = 0); ```
## Read
Dependencies are detected automatically when the read function is run during initiation.
```js read(".counter", ctx => ctx.el.textContent = `Count: ${ctx.count}`); ```
## Write
Immediate:
```js write(ctx => ctx.count++); ```
Event-triggered:
```js write(".increment", "click", ctx => ctx.count++); ```
Event writes expose `ctx.el` and `ctx.event`.
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.
https://github.com/tc39/proposal-signals)
It’s a very smart idea though, I like it.
> 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.
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.