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

51–60 of 138 posts

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

#51

Post by jmull »

vanviegen wrote: post #39
jmull wrote: 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.

It's not a question of HTML's syntax.

1. HTML is a widely implemented standard. What you learn and know about HTML, and what you create with HTML is widely applicable. Not so much for your HTML alternatives, like Aberdeen.

2. HTML is what the browser accepts, which means you end up dealing with it anyway, just with a transformation in between, making things harder. The bigger the transformation the harder it is. To develop with Aberdeen you still need to know HTML, but you also need to know Aberdeen and how it transforms into HTML. And, you typically end up needing to learn how to mentally transform backwards as you debug, e.g., using the browser dev tools, looking at problem HTML, and deciding how to change the Aberdeen code to fix it.

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

#52

Post by vanviegen »

xiphias2 wrote: post #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/databa…

> 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)

Based on the current proposals, it seems that a signal can only contain a single atomic value, for which changes can be tracked. Aberdeen's `proxy` can efficiently wrap complex data structures (objects within arrays within objects, etc), tracking changes on the level of primitive values (integers, strings).

For that reason, I wouldn't really call Aberdeen signals based.

Yeah, "what data to sync and when" describes the problem quite nicely! And indeed, it's entirely different from this library, except that I have a partial solution in mind that may fit Aberdeen rather well... We'll see. :-)

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

#53

Post by vanviegen »

WorldMaker wrote: post #50
vanviegen wrote: post #33

Earlier quoted context omitted.

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. :-)

> Also, in order to transform JSX into individual rerunnable functions, we'd need a whole different transpiler. I don't think you would. ` ` gets converted by current transpilers into `jsx(Component, { prop: "example" })`. The `Component` itself is passed as is. In the case of Components that are just functions, that passes the function as-is, as a function you can just call as needed. JSX was built for "rerunnable f…

The problem is that JSX transpilers will put child nodes in an array, instead of in an anonymous function, meaning there is no easy way (without transpiler magic) to rerender just a part of the component.

This JSX:

  Welcome{data.enabled ?  : "disabled"}
Which becomes this with Babel:

  _jsx("section", {children: [
    _jsx("h1", {children: "Welcome"}),
    data.enabled ? _jsx("input", {}) : "disabled"
  ]})
But we'd need something like this to fit Aberdeen:

  _jsx("section", ()=>{
    _jsx("h1", ()=>{_jsx("Welcome");});
    if (data.enabled) _jsx("input", {}) else _jsx("disabled");
  }})
In React you can, with some effort, limit virtual DOM rerenders to a single component. Aberdeen rerenders fractions of components by default, if that's all that needs to happen. That's why it works well operating directly on the actual DOM, without a virtual DOM inbetween.

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

#54

Post by lhorie »

JSR_FDED wrote: post #44

Very interesting. How would you say it compares to mithril.js?

(mithril.js author here)

As far as I can tell, the main difference is this uses proxies to trigger side effects as opposed to virtual dom diffing. Perf wise, I like that people are pushing the boundaries, but also obviously React is still very popular and that indicates that its level of performance is good enough for a lot of devs .

In terms of features:

- This was already pointed out in another comment, Aberdeen doesn't seem to be JSX compatible, but it supports similar hyperscript-like syntax (e.g. $('div.foo:hi') vs m('.foo', 'hi'))

- Unclear what the level of support is for various features that exist in Mithril. e.g. Router appears to be an add-on/example, and I don't see anything about HTTP request utils or SVG/MathML. Mithril is meant to be sort of a one-stop shop for SPAs; it could just be that the focus of the two libraries is slightly different, and that's ok if that's the case.

- Mithril has hooks to access the raw DOM and uses RAF for batching, it's not clear to me how integration w/ other DOM-touching libs (e.g. dragula) would work here.

I like the idea of using proxies as a way of implementing reactivity in principle, and I even played around with that idea. IME, there were a couple of things that made it problematic w/ POJO models IMHO. The first is that proxies are not friendly to console.log debugging, and the second is that implementing reactivity in collections (Map/Set/Weak*) was getting a bit too complex for my minimalist tastes.

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

#55

Post by vanviegen »

charles_f wrote: post #23

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", ).

Yeah, I know what you mean - I went back and forth about that API decision a couple of times. :-)

What landed me on $ was that a don't like polluting my namespaces with function named `a`, `b`, `p`, `form`, `input`. And you'll often want to add CSS classes, so you'll have to create a "string" anyway. Also, we'd need a generic $-like function anyway, for less common tags and for attaching properties/behavior/text content to the 'current' element.

Back in the CoffeeScript days, we did at some point expose HTML tags as function though, and it made for awesome looking (though very error-prone) code! :-)

  form ->
    h2 "Sign up"
    input placeholder: "Name", bind: name

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

#56

Post by WorldMaker »

vanviegen wrote: post #53
WorldMaker wrote: post #50

Earlier quoted context omitted.

> Also, in order to transform JSX into individual rerunnable functions, we'd need a whole different transpiler. I don't think you would. ` ` gets converted by current transpilers into `jsx(Component, { prop: "example" })`. The `Component` itself is passed as is. In the case of Components that are just functions, that passes the function as-is, as a function you can just call as needed. JSX was built for "rerunnable f…

The problem is that JSX transpilers will put child nodes in an array, instead of in an anonymous function, meaning there is no easy way (without transpiler magic) to rerender just a part of the component. This JSX: Welcome {data.enabled ? : "disabled"} Which becomes this with Babel: _jsx("section", {children: [ _jsx("h1", {children: "Welcome"}), data.enabled ? _jsx("input", {}) : "disabled" ]}) But we'd need somethin…

Your `_jsx` function can auto-wrap children in a function. Also, you can just pass functions as children, too if you really want to make the JSX author work for it:

    Welcome{ () => data.enabled ?  : "disabled" }
That doesn't even look half bad to me. It looks really close to many of your other examples.

> In React you can, with some effort, limit virtual DOM rerenders to a single component. Aberdeen rerenders fractions of components by default, if that's all that needs to happen. That's why it works well operating directly on the actual DOM, without a virtual DOM inbetween.

A lot of that depends on what your model of a "component" is. React will rerender fractions of a component in advanced areas such as a Error Boundaries and Suspense.

Also, for what little it is worth, my JSX-based library isn't a virtual DOM, operates directly on the actual DOM, and generally renders components once and only once in their lifetime, because it binds all changes even more directly to specific DOM properties.

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

#57

Post by bufferoverflow »

1) this is the opposite of elegant. Something that can be expressed in a few clean lines of html + css turned into a wall of barely readable JS, where you have to jump between functions just to find the correct place in the DOM tree.

2) why do you call it "declarative"? This is procedural. React or Vue is more declarative (you declare the state, and it renders based on the state).

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

#58

Post by test1235 »

GordonS wrote: post #46

Which Aberdeen was the inspiration behind the name? (I'm near the original Aberdeen in Scotland, but I know there's at least one in Australia and several in the US too).

There's also one in Hong Kong, surprisingly.

Fellow Aberdonian represent

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

#59

Post by GordonS »

test1235 wrote: post #58
GordonS wrote: post #46

Which Aberdeen was the inspiration behind the name? (I'm near the original Aberdeen in Scotland, but I know there's at least one in Australia and several in the US too).

There's also one in Hong Kong, surprisingly. Fellow Aberdonian represent

Fit like!? (had to be said)

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

#60

Post by arnorhs »

Congrats on making it to V1!

Though not immediately obvious, there's a lot of parallels to be drawn between this and solid.js (proxy is a sort of `signal` right?, no virtual dom) - I'd be curious what you'd say are the primary benefits of this library over something like Solid.js?

I gotta turn a little negative here...

Off the bat, regarding the first point in the "Why use Aberdeen?" section, I have a few nit-picks:

- "Elegant and simple" - Is it though? Developers should in general be more careful about conflating simple with easy - "Elegant and easy" is probably more accurate, since having a magic proxy function, that will ensure that registered functions will be re-run etc does not constitute "simple" to me.

- "Express UIs naturally in JavaScript/TypeScript, without complex abstractions, build steps, or JSX." - I agree that having an option in the UI library space, where it is no-JSX fist can be a huge benefit in a lot of cases. Personally, these days, given how many ways you can transform and use JSX, I doubt a lot of people feel like that's a huge benefit. And in many ways, it's more natural to express DOM structures as JSX-ish components.

- "No hooks, no setState, no lifting state, no state management libraries." - this is just plain gaslighting. You may not call your API's functions "hooks" and you may very well not call your "proxy()" function a `useState` / `createStore` - but people are still using them the same way... and you end up having to solve all the same issues as with all those libraries

- "Just proxied data and automatically rerunning functions." - this is a big "just"

You are pretending that this library does away with a lot of things that are the bread and bones of other UI libraries but then your UI library still needs all those things.

I'm also curious how your proxy() handles the diamond problem in reactive state, if at all.

--

I have nothing against people building UI libraries for fun - and finding specific use cases where the libraries work well.

Eg. focusing on the lack of build can be a big benefit to a lot of projects / setups that don't perhaps have any kind of build facility etc.. also thinking about "copy pasted scripts" etc - but trying to frame it in a way that it is superior to using something like JSX seems like gaslighting to me.

On a side note, the re: typescript - you do not seem to have strict settings when developing - (from looking at the code examples) - that is already a bit of a red flag and I'd be worried I'd have a lot of TS issues when using the library.

I'll try it out when I get home, and sorry about being so negative.

Post reply on HN