Live data from Hacker News

Show HN: Aberdeen – An elegant approach to reactive UIs

aberdeenjs.org

131–138 of 138 posts

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

#131
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/

I just saw your todo list. One issue is that all the work is done in the view. Suppose I want to toggle or clear items programmatically instead of via UI. This is why I suggested the todo example, because it goes one level deep, which is more than zero, just enough to show-case how the model and view interoperate in a way that's not just the same as backbone.js, which so far this looks exactly like.

[edit]: That's also why I suggested a button to inverse all todo items. This would have forced you to pull some code out of the view constructor for a todo item and I wanted to see where it would go and how it would all connect.

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

#132
post #124

Earlier quoted context omitted.

Huh. I guess in my trend-chasing days we just called that event driven programming.

It basically is that, although the key idea with signals is the automatic tracking. There's no sort of `signal.subscribe()` call happening, instead any time you use a signal inside a reactive context, it automatically gets subscribed. This simplifies a lot of patterns that would otherwise be rather complicated. For example, you might have an effect like: if (showName()) { console.log(name()); } else { console.log("th…

Thanks, this is an insightful explanation.

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

#135
post #108

Earlier quoted context omitted.

examples?

Examples of what? Do you mean examples of not using React?

I think he meant examples where "Managing and updating the DOM is stupid simple." The consensus here seems to be that updating the DOM is a difficult problem. It would be nice to have counter-examples.

https://news.ycombinator.com/item?id=43734312

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

#136

Earlier quoted context omitted.

Examples of what? Do you mean examples of not using React?

I think he meant examples where "Managing and updating the DOM is stupid simple." The consensus here seems to be that updating the DOM is a difficult problem. It would be nice to have counter-examples. https://news.ycombinator.com/item?id=43734312

I am sure it is hard if you have never written an application without React, jQuery, whatever before. That doesn't make it hard though. It just means its something, only at present, uncomfortable.

Here is how I do it. This is all the front end code for a large personal project.

https://github.com/prettydiff/webserver/blob/main/lib/dashbo...

My observation is that no matter how complicated and large the application gets anything that ultimately runs in the browser scales in size disproportionately slower in the browser code than elsewhere. This remains true no matter how much of the instruction set you intentionally try to put into the browser. That said, why even bother with this framework bullshit in the first place if the code it abstracts is never the primary problem in any given application? The larger the application gets the less significant the browser portion of that code becomes as a percentage of total application size.

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

#137

Earlier quoted context omitted.

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

Considering there's no written html and no server side, how do you deal with SEO? (taking into account the possibility of non-JS agents)

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

#138

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

> it looks at lot cleaner

It always gets me when people say "cleaner" because the concept of cleanliness is subjective yet you see devs throw it around as if their views were the views of everyone and evidently right by any measure possible.

Post reply on HN