Show HN: Aberdeen – An elegant approach to reactive UIs

The first was using Edit: The other premature concern/feature was the ability to have a for loop NOT render to an array and rather be inline.

Normaly

    for (...) { yield ... }
    // becomes
    [[..., ..., ...]]

    "use jsxg:inline"
    for (...) { yield ... }
    // becomes
    [..., ..., ...]

Yes, there's some similarity to Solid.js, but also two big differences:

1. A Solid.js signal contains a single atomic value that can be subscribed to, while an Aberdeen proxy can wrap around a complex object (containing arrays containing objects, etc), and subscribe to only the primitive values that were read.

2. If I understand correctly, Solid.js can only redraw entire components (which may not be great at it, like Aberdeen, doesn't use a VDOM), while Aberdeen creates observer scopes every time you nest DOM elements (or manually, if that is not enough for some specific case).

So Aberdeen is more finegrained on both counts. And there's no need for createMemo and createEffect.

Re "Elegant and simple": the Aberdeen internals are far from simple, but I think its semantics are very simple to understand. Especially when compared to monsters like React. But I'd settle for easy. :-)

> "And in many ways, it's more natural to express DOM structures as JSX-ish components."

Yeah, until you want to add some loops and conditionals in there. That's what regular programming languages are really good at. But it's a trade-off for sure.

> "this is just plain gaslighting" ... " and you end up having to solve all the same issues as with all those libraries"

I don't think that's the case. In my (admittedly colored) experience, Aberdeen allows you to do the same things while having to learn far fewer concepts.

But reading back my text, the claim could have better just said that, as replacing a ton of complex concepts with a ton of different but equally complex concepts is not better. I've updated the site.

> You are pretending that this library does away with a lot of things that are the bread and bones of other UI libraries but then your UI library still needs all those things.

My claim is that we don't, in fact, need all those things. As Aberdeen takes a rather different approach, we do of course need some other things (as you pointed out earlier), but I believe this approach allows us to have less of them.

Re "Diamond problem": I haven't heard the term before, but Aberdeen solves this by a) batching updates (using a setTimeout 0 by default) and b) rerunning all dirtied scopes in the order that they were initially created.

> but trying to frame it in a way that it is superior to using something like JSX seems like gaslighting to me.

I'd be happy to add more downsides to the why-NOT-to-use-this list, but my rose colored glasses seem to prevent me from articulating something that makes sense there. :-)

Re "TypeScript" safety: It says `"strict": true` in the config file. Any other settings you'd want on? Also, the lib has 100% test coverage, if you're into that sort of thing! :-)