Live data from Hacker News

Show HN: Aberdeen – An elegant approach to reactive UIs

aberdeenjs.org

31–40 of 138 posts

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

#32

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 ve…

At first glance and on a syntax level, Vue from the start had part of its code in html syntax and the rest on JS. Aberdeen goes fully into JS.

So if I get it right, in Aberdeen there would not be any pure html written at all, right? Is that the "ideal"? Or it would be more of a hybrid with Aberdeen accompanying plain html?

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

#33

Why not JSX? There’s no real cost to making the API JSX compatible, from what I can tell, and tsc has builtin support for transpiling JSX. It would also make porting code a lot easier. I’m only saying this because the type signature of $ is so similar to createElement. As an aside, I really like the class name and text content ergonomics (e.g div.someclass, span:some content). Reminiscent of pug/jade

I don't particularly like how control logic needs to be embedded within JSX using ?ternary : operators and .map(() => stuff) within the HTML.

Also, in order to transform JSX into individual rerunnable functions, we'd need a whole different transpiler. I like being able to code browser-runnable JavaScript directly.

To each their own. :-)

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

#34

Why not JSX? There’s no real cost to making the API JSX compatible, from what I can tell, and tsc has builtin support for transpiling JSX. It would also make porting code a lot easier. I’m only saying this because the type signature of $ is so similar to createElement. As an aside, I really like the class name and text content ergonomics (e.g div.someclass, span:some content). Reminiscent of pug/jade

I don't particularly like how control logic needs to be embedded within JSX using ?ternary : operators and .map(() => stuff) within the HTML. Also, in order to transform JSX into individual rerunnable functions, we'd need a whole different transpiler. I like being able to code browser-runnable JavaScript directly. To each their own. :-)

You don't have to do that in the html if you don't want to. You can easily assign those operations to a variable then insert the variable into the html.

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

#36

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.

> 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

Yeah, that's probably a good idea. Aberdeen doesn't prescribe any 'standard' for how components should be implemented; they're just functions that draw stuff after all. But figuring out some best-practices may not hurt!

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

You'd think that in 2025, I'd remember to test my pages on a mobile phone, right? Doh! :-)

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

#37
> Express UIs naturally in JavaScript/TypeScript

I would disagree there. Conceptually, you're writing reactive HTML and CSS. I think it would be a lot more natural to express HTML and CSS using HTML and CSS (with extensions to add reactivity), not Javascript/Typescript.

(Svelte is an example of this, though it has it other issues, IMO)

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

#38

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 ve…

At first glance and on a syntax level, Vue from the start had part of its code in html syntax and the rest on JS. Aberdeen goes fully into JS. So if I get it right, in Aberdeen there would not be any pure html written at all, right? Is that the "ideal"? Or it would be more of a hybrid with Aberdeen accompanying plain html?

Correct!

As far as I know, Vue has always had its own HTML-based template engine, with special HTML attributes for conditions, loops, etc. Different trade-off.

Since Vue 3, it does indeed rely on `Proxy` for its reactivity, like Aberdeen.

The idea is the write whole applications without HTML. We've done some pretty big projects in this style, and in terms of DX and velocity it's actually really good. Recycling (tiny) components becomes really easy, as it's all just JavaScript functions.

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

#39
post #37

> Express UIs naturally in JavaScript/TypeScript I would disagree there. Conceptually, you're writing reactive HTML and CSS. I think it would be a lot more natural to express HTML and CSS using HTML and CSS (with extensions to add reactivity), not Javascript/Typescript. (Svelte is an example of this, though it has it other issues, IMO)

Meh, I think there's nothing magical about the HTML syntax that makes it particularly great for expression DOM structures. Except familiarity of course.

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

#40
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.

Post reply on HN