Live data from Hacker News

Show HN: Aberdeen – An elegant approach to reactive UIs

aberdeenjs.org

41–50 of 138 posts

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

#41
post #24

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

Thanks!

Yeah, creating a todo-list demo was actually on my, eh... todo-list! :-)

I'll probably implement this one soon: https://todomvc.com/

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

#42

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

JSX is a better data structure than strings for expressing views, but this doesn’t use strings or any other data structure.

The beauty of the OP’s approach is the immediate mode render approach. JSX is a data structure, immediate mode implies a structure from the order of execution of computation.

You need JSX to pass around fragments of a view, unless your view is made entirely of computation, in which case you can just pass around functions.

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

#43

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

The signature looked compatible with JSX to me. You could probably easily create JSX functions that just use $ internally, and make your web build tool's react-auto-import setting point to it.

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

#45
post #24

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

> "lack of community" and "lack of ecosystem"

Yes, those absolutely are downsides - they materially affect my choice, as a developer, to use the framework or not.

The fact that they're solvable doesn't make them not negative. Other frameworks could solve their problems, too - that doesn't mean that they aren't problems now.

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

#49
post #42

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

JSX is a better data structure than strings for expressing views, but this doesn’t use strings or any other data structure. The beauty of the OP’s approach is the immediate mode render approach. JSX is a data structure, immediate mode implies a structure from the order of execution of computation. You need JSX to pass around fragments of a view, unless your view is made entirely of computation, in which case you can…

JSX does not have any inherent data structure, it immediately converts to function calls. React is well known for taking the JSX calls and converting them to a reusable data structure, but that's React's thing and React's data structure is somewhat unique to React, other virtual DOM's have different data structures.

You can do "immediate mode" JSX. There's nothing technical stopping you, and there are at least a few libraries out there that do.

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

#50

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

> 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 functions". It's a lot of how React works under the hood.

Post reply on HN