Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Aberdeen – An elegant approach to reactive UIs

aberdeenjs.org

Post reply on HN
Print view View original

21–30 of 138 posts

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#21

Post by vanviegen »

phartenfeller wrote: post #14

Not for me as I like looking at actual HTML but definetly intersting. Good job! I also like Svelte which uses it's own language and needs transpilation. I think that's key to elegance as JS was not really designed to control layout, style and logic all at once.

It takes some getting used to, but the advantage of using JavaScript for layout, is that it mixes well with your control logic. JSX makes loops and ifs hard to look at. Svelte/Vue/etc invent templating languages with their own control logic - while we're already running within a full-fledged language.

Originally, we did this style of programming in CoffeeScript. Without all of the braces, it looks at lot cleaner. :-)

Svelte is one of the frameworks I stuck with the longest. There's a lot to like. What I didn't like was the gotchas around change tracking. I guess runes is intended to fix that, but... damn. :-)

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#22

Post by Etheryte »

Conceptually, this sounds incredibly similar to what Vue was in the 0.x stage. Are you familiar with Vue perhaps? What would you say are the core conceptual differences? At a glance, both aim for the same idea, that your data is proxied, you detect what changes actually matter, and you try and wrap all of that up in a neat little package. These days of course Vue is a larger beast, but I feel like the origins were very similar to what you have here. Interested to hear what you think about this comparison.

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#23

Post by charles_f »

You might consider to add shorthands for at least the common components (eg div(...) instead of $('div',...). The funny thing is that I somehow ended up rebuilding a simple version of that a couple of times, and it looks a bit more natural (plus it gets old typing that "div", ).

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#24

Post by 90s_dev »

The two downsides you list ("lack of community" and "lack of ecosystem") are not really downsides. If something is good enough, people will simply adopt it out of excitement, and those two problems will disappear entirely. See Rust and React.

This looks and sounds incredibly clever, and seems to be what I always wanted React to be. I'm eager to try it out!

Could you make a demo of a simple Todo list app in it that lets you edit items, toggle them complete individually, inverse all items, and delete all done items? That way we can see how this works with relatively complex hierarchies.

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#25

Post by omneity »

Very interesting approach, congrats on your release!

Have you noticed any practical performance overhead related to the usage of Proxy objects? Granted, that might not be the area of focus you have in mind for Aberdeen. I'm just asking as I mused on a similar idea some time ago and always felt hindered by this point.

My second question is related to composition and reactivity (computed fields and other transformations happening _outside_ the components). Do you see any particular pattern working well with Aberdeen?

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#26

Post by vanviegen »

qudat wrote: post #4

This seems similar to https://github.com/pmndrs/valtio but built directly into the view library, neat!

Oh.. yeah, the proxy part does look really familiar! :-)

Also, their use of promises looks interesting: https://github.com/pmndrs/valtio?tab=readme-ov-file#suspend-... -- I might borrow some ideas from that... :-)

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#29

Post by vanviegen »

omneity wrote: post #25

Very interesting approach, congrats on your release! Have you noticed any practical performance overhead related to the usage of Proxy objects? Granted, that might not be the area of focus you have in mind for Aberdeen. I'm just asking as I mused on a similar idea some time ago and always felt hindered by this point. My second question is related to composition and reactivity (computed fields and other transformation…

I had similar concerns when I made the jump from a custom data class (with methods like `set`, `get`, `increment`, `push`, etc) to a transparent `Proxy` around native JavaScript objects. I did some quick benchmarks back then, and concluded that it was actually not meaningfully slower. Modern JavaScript engines are awesome! :-)

Aberdeen is not in js-framework-benchmark yet, but I've done a pull request https://github.com/krausest/js-framework-benchmark/pull/1877 -- By my own testing, performance is similar to something like react (while of course destroying React on time-to-first-paint, bytes transferred, etc). However, this test is not a particular good fit for Aberdeen, as lists in Aberdeen are always sorted by a given key (it maintains an ordered skiplist for the data). The test only requires the easy case: sort by creation time. So Aberdeen is doing some extra work here.

With regard to reactive data transforms: Aberdeen provides some (reactively 'streaming') helper functions for that (`map`, `multiMap`, `partition`, `count`). But these are mostly based on the `onEach` primitive, for reactive iteration. Take a look at the `map` implementation, for instance: https://github.com/vanviegen/aberdeen/blob/a390ce952686da875...

Is past projects, we've been using things like this a lot. Pretty easy and fast!

Re: Show HN: Aberdeen – An elegant approach to reactive UIs

#30

Post by tacitusarc »

Congrats! Building something like this is not trivial. You should be proud.

I think it would be useful to have an example of how to make “widgets”, larger components with more complex behaviors that could be reused across many applications.

I recommend making the HTML boxes scrollable, and allowing the code to scroll x. Reading wrapped code on a small screen is difficult.

Post reply on HN