Show HN: Aberdeen – An elegant approach to reactive UIs

Though not immediately obvious, there's a lot of parallels to be drawn between this and solid.js (proxy is a sort of `signal` right?, no virtual dom) - I'd be curious what you'd say are the primary benefits of this library over something like Solid.js?

I gotta turn a little negative here...

Off the bat, regarding the first point in the "Why use Aberdeen?" section, I have a few nit-picks:

- "Elegant and simple" - Is it though? Developers should in general be more careful about conflating simple with easy - "Elegant and easy" is probably more accurate, since having a magic proxy function, that will ensure that registered functions will be re-run etc does not constitute "simple" to me.

- "Express UIs naturally in JavaScript/TypeScript, without complex abstractions, build steps, or JSX." - I agree that having an option in the UI library space, where it is no-JSX fist can be a huge benefit in a lot of cases. Personally, these days, given how many ways you can transform and use JSX, I doubt a lot of people feel like that's a huge benefit. And in many ways, it's more natural to express DOM structures as JSX-ish components.

- "No hooks, no setState, no lifting state, no state management libraries." - this is just plain gaslighting. You may not call your API's functions "hooks" and you may very well not call your "proxy()" function a `useState` / `createStore` - but people are still using them the same way... and you end up having to solve all the same issues as with all those libraries

- "Just proxied data and automatically rerunning functions." - this is a big "just"

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.

I'm also curious how your proxy() handles the diamond problem in reactive state, if at all.

--

I have nothing against people building UI libraries for fun - and finding specific use cases where the libraries work well.

Eg. focusing on the lack of build can be a big benefit to a lot of projects / setups that don't perhaps have any kind of build facility etc.. also thinking about "copy pasted scripts" etc - but trying to frame it in a way that it is superior to using something like JSX seems like gaslighting to me.

On a side note, the re: typescript - you do not seem to have strict settings when developing - (from looking at the code examples) - that is already a bit of a red flag and I'd be worried I'd have a lot of TS issues when using the library.

I'll try it out when I get home, and sorry about being so negative.

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! :-)