←back to thread

Show HN: Aberdeen – An elegant approach to reactive UIs

(aberdeenjs.org)
224 points vanviegen | 3 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 #
austin-cheney ◴[09 May 25 16:47 UTC] No.43938808[source]▶
I just read the signals proposal and was not impressed. There is a lot group thought in JavaScript, in Java too but more in JavaScript, around standardizing convenience based upon knowingly bad decisions from convenience abstractions.

Managing and updating the DOM is stupid simple and that simplicity has nothing to do with state, which a fully separate yet equally simplistic concern. That is something UI frameworks most commonly fail at horribly with a mountain of highly complex state bullshit that is forced on everything. But because framework people cannot architect original applications at any level these failures become indefensible standards enshrined by the most insecure among us.

replies(1): >>43941839 #
llbbdd ◴[09 May 25 23:19 UTC] No.43941839[source]▶
examples?
replies(1): >>43942762 #
1. austin-cheney ◴[10 May 25 02:26 UTC] No.43942762[source]▶
Examples of what? Do you mean examples of not using React?
replies(1): >>43953853 #
2. lylejantzi3rd ◴[11 May 25 13:56 UTC] No.43953853[source]▶
I think he meant examples where "Managing and updating the DOM is stupid simple." The consensus here seems to be that updating the DOM is a difficult problem. It would be nice to have counter-examples.

https://news.ycombinator.com/item?id=43734312

replies(1): >>43957143 #
3. austin-cheney ◴[11 May 25 21:03 UTC] No.43957143[source]▶
I am sure it is hard if you have never written an application without React, jQuery, whatever before. That doesn't make it hard though. It just means its something, only at present, uncomfortable.

Here is how I do it. This is all the front end code for a large personal project.

https://github.com/prettydiff/webserver/blob/main/lib/dashbo...

My observation is that no matter how complicated and large the application gets anything that ultimately runs in the browser scales in size disproportionately slower in the browser code than elsewhere. This remains true no matter how much of the instruction set you intentionally try to put into the browser. That said, why even bother with this framework bullshit in the first place if the code it abstracts is never the primary problem in any given application? The larger the application gets the less significant the browser portion of that code becomes as a percentage of total application size.