←back to thread

Show HN: Aberdeen – An elegant approach to reactive UIs

(aberdeenjs.org)
224 points vanviegen | 2 comments | 09 May 25 12:42 UTC | HN request time: 0s | source

Yes, another reactive UI framework for JavaScript. Bear with me, please... :-)

I 'invented' the concept for this back in 2011, and it was used (as a proprietary lib) in various startups. Even though many similar open source libs have been released since, and boy have I tried a lot of them, none have been able to capture the elegance and DX of what we had back then. I might be biased though. :-)

So I started creating a cleaned-up, modern, TypeScript, open source implementation for the concept about five years ago. After many iterations, working on the project on and off, I'm finally happy with its API and the developer experience it offers. I'm calling it 1.0!

The concept: It uses many small, anonymous functions for emitting DOM elements, and automatically reruns them when their underlying proxied data changes. This proxied data can be anything from simple values to complex, typed, and deeply nested data structures.

As I'm currently free to spend my time on labors of love like this, I'm planning to expand the ecosystem around this to include synchronizing data with a remote server/database, and to make CRUD apps very rapid and perhaps even pleasurable to implement.

I've celebrated 1.0 by creating a tutorial with editable interactive examples! https://aberdeenjs.org/Tutorial/

I would love to hear your feedback. The first few people to actually give Aberdeen a shot can expect fanatical support from me! :-)

Show context
xiphias2 ◴[09 May 25 14:43 UTC] No.43937339[source]▶
Congrats for reaching 1.0! Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal (https://github.com/tc39/proposal-signals)

At the same time for me, while it's super nice, in my opinion it just doesn't differentiate enough from other signals based frameworks to get mass adopted / make CRUD apps that much easier to make.

The problem with remote server/database is ,,what data to sync and when'' by the way, it's very different problem from what your framework is solving.

I loved Svelte until I started using SvelteKit and realized how hard the data synchronization part is.

replies(4): >>43938046 #>>43938808 #>>43938916 #>>43943191 #
boredtofears ◴[10 May 25 04:17 UTC] No.43943191[source]▶
> Nice little library, but as it's signals based

How do you reach that conclusion? There is nothing mentioning signals in the docs anywhere.

replies(1): >>43943261 #
MrJohz ◴[10 May 25 04:33 UTC] No.43943261[source]▶
The proxy object is a fairly classic way of doing signals (see Vue, SolidJS), and the whole thing about functions rerunning whenever data that was accessed inside that function changes is pretty much the definition of signals.

It looks like the author is trying to avoid making direct comparisons with signals and existing signal frameworks, which makes sense - depending on your target audience, it can be a bit "inside baseball" - but it's definitely using some sort of signals-like mechanism under the hood.

replies(1): >>43943474 #
boredtofears ◴[10 May 25 05:44 UTC] No.43943474[source]▶
Huh. I guess in my trend-chasing days we just called that event driven programming.
replies(1): >>43943778 #
1. MrJohz ◴[10 May 25 07:07 UTC] No.43943778[source]▶
It basically is that, although the key idea with signals is the automatic tracking. There's no sort of `signal.subscribe()` call happening, instead any time you use a signal inside a reactive context, it automatically gets subscribed. This simplifies a lot of patterns that would otherwise be rather complicated. For example, you might have an effect like:

    if (showName()) {
      console.log(name());
    } else {
      console.log("the name is a secret");
    }
In this case, both `showName` and `name` are signals. If `showName()` is true, then the effect will automatically subscribe to both signals, and this function will rerun every time the name changes, or someone toggles `showName`. But if it's false, then the effect will only subscribe to the `showName` signal, which means even if the name changes somewhere else, that won't affect this expression at all.

In complex situations, it can be harder to see where the reactivity is flowing without the explicit subscriptions, especially at first, but it's also a lot more intuitive to just use data and have it automatically become reactive where it makes sense. It's also the base for most major web frameworks outside of React.

replies(1): >>43946723 #
2. boredtofears ◴[10 May 25 16:05 UTC] No.43946723[source]▶
Thanks, this is an insightful explanation.