←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: 0.606s | 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! :-)

1. jdonaldson ◴[09 May 25 18:55 UTC] No.43939941[source]▶
I remember the concept of the virtual dom had to be explained very carefully so people understood why it led to more efficiency when rendering (e.g.) scrolling content.

Is there a technical trick that one takes that can beat a virtual dom use case? What is it?

replies(2): >>43940156 #>>43943599 #
2. vanviegen ◴[09 May 25 19:23 UTC] No.43940156[source]▶
Yes, it's an easy trick: just rerender the tiny parts of the DOM that actually need to change. Like Svelte does, only with run-time magic, instead of compile-time magic.
3. MrJohz ◴[10 May 25 06:22 UTC] No.43943599[source]▶
The virtual DOM doesn't really lead to better efficiency, that's a bit of a myth. It's really a UX tool: it means that you can treat rendering as a pure operation (i.e. (state) => UI), and recreate as much of the UI tree as you like whenever you want, without interacting with the DOM directly. Then, at a different point in time, you can diff that virtual tree with the real DOM tree and only make the necessary changes.

This is always going to be slower than a framework like this or Solid or Vue or whatever, which just skips to the last step and only make the necessary changes in the DOM.

Another way to think about it if you're familiar with different forms if GUI rendering is that React is an immediate mode abstraction sitting in top of a retained mode system. In React, theoretically, the render functions could run at 60fps, constantly churning out the same values. In practice this isn't very performant, so React has its own rubrics for when to rerun the render functions, but that's why, for example, it's fine for React to do its weird double-render thing in dev mode. However, at the end of the day, the DOM doesn't work like that, so React needs to diff everything back into DOMland.