Live data from Hacker News

Show HN: Aberdeen – An elegant approach to reactive UIs

aberdeenjs.org

71–80 of 138 posts

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

#71
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

Named after Lord Aberdeen (born in Edinburgh)

https://en.wikipedia.org/wiki/George_Hamilton-Gordon,_4th_Ea...

> His diplomatic successes include organizing the coalition against Napoleon in 1812–1814, normalizing relations with post-Napoleonic France, settling the old border dispute between Canada and the United States, and ending the First Opium War with China in 1842, whereby Hong Kong was obtained.

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

#72

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

[dead]

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

#73

Earlier quoted context omitted.

The Scottish one! My girlfriend used to live there for half a year doing her Master's. I also once made Glasgow (a React-clone created for educational purposes, when I was a CS teacher). So named, because it is ugly. ;-) https://www.npmjs.com/package/glasgow I'm not sure what Edinburgh is going to be yet, but it would probably need to be rather iconic. :-)

> I'm not sure what Edinburgh is going to be yet Something with several layers? Old town, New town and space between.

Also with a prohibitively expensive license fee.

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

#74

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

1. You see a "wall of barely readable JS" somewhere? Eye of the beholder, I suppose.. ?

2. Perhaps "reactive" would have been a better term. In fact, I'll change it. To me, the difference with procedural is that functions automatically rerun when the data they access changes.

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

#75
post #2

I haven't had time to dig into this yet but I played the tic-tac-toe demo at the bottom of the page and it seems pretty interesting. The code is easy to understand. How do you see this being used in a "real" application? Do you see it providing most/all of the reactivity or integrating with an existing framework or library?

That's good the hear!

I intend this to be used to write full applications. I've used to proprietary spiritual predecessor to Aberdeen for pretty large projects.

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

#76

Earlier quoted context omitted.

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…

No matter how one turns it, JSX is still something different from plain JS. It is a kind of format, that needs to be parsed and interpreted. Writing only plain JS from that perspective is a purer approach than having JSX anywhere.

> It is a kind of format, that needs to be parsed and interpreted

Yes, but this happens at build time, not run time.

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

#77
post #54

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

Thanks for your input! Although I've never had a good excuse to use it yet, I've glanced at mithril.js quite a few times, and I really appreciate the apparent simplicity and the batteries-included philosophy.

Indeed, the main difference with Aberdee is in the way change tracking and updates are handled. This is actually a pretty significant, both in terms of internals and in the way you use the framework.

Fun fact: I once created a another library (for educational purposes) that's a lot more similar to mithril (though not as fully featured): https://www.npmjs.com/package/glasgow

As I said, I'm a fan of mithril's batteries-included approach. The router is part of Aberdeen, but not imported by default. SVG support is on my todo-list. And I'll be exploring nice ways to integrate with some backends.

Aberdeen allows (but discourages) you to access the raw DOM as well (through `getParentElement()`), as long as you don't detach/move nodes it created.

I don't know and can't find what you mean by RAF batching. Aberdeen batches all updates (using a setTimeout 0), and then reruns all dirty scopes in the order that they were created. That also means that parent-scopes go before child-scopes, cancelling the need for separately updating the latter.

It seems that console.log debugging of proxied objects works pretty well (now, in Chrome at least). It shows that it's a proxied object, and it shows the contents, without subscribing, which is usually what you'd want for debugging. If you do want to subscribe, a `console.log({...myObj})` does the trick. Or use `clone()` (provided by Aberdeen) for recursively subscribing to deep data structures.

I apparently have the same minimalist taste, having recently removed Map support to simplify things. :-) I'll probably have another go at adding Map/Set/Weak* once I figure out how to do it without with a tiny amount of code. :-)

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

#79

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: syntax, I agree, it's stopped me from ever trying React/JSX-based frameworks, which I am sure is an over-reaction.

I have a POC syntax extension (babel parser fork) I named JSXG where I introduced "generator elements" which treats the body of the element as a JS generator function that yields JSX elements.

The simple/naive implementation of just running the generator was okay, but I (perhaps prematurely) worried that it would be not ideal to have the resulting list of child elements be actually dynamic-- as opposed to being fixed size but have false/null in place of "empty" slots and also using arrays for lists made by loops.

So, I also had a transform that followed conditional branching and loops etc. and made a template of "slots" and that resulted in a stable count of children, and that improved things a whole lot.

It's been a while since I revisited that, I should try and find it!

Comparisons below.

Aberdeen:

    $('div', () => {
      if (user.loggedIn) {
        $('button.outline:Logout', {
          click: () => user.loggedIn = false
        });
      } else {
        $('button:Login', {
          click: () => user.loggedIn = true
        });
      }
    });

    $('div.row.wide', {$marginTop: '1em'}, () => {
        $('div.box:By key', () => {
            onEach(pairs, (value, key) => {
                $(`li:${key}: ${value}`)
            });
        })
        $('div.box:By desc value', () => {
            onEach(pairs, (value, key) => {
                $(`li:${key}: ${value}`)
            }, value => invertString(value));
        })
    })
JSX:

    
      {user.loggedIn ? (
         user.loggedIn = false}
        >
          Logout
        
      ) : (
         user.loggedIn = true}>
          Login
        
      )}
    

    
      
        By key
        
          {Object.entries(pairs).map(([key, value]) => (
            
              {key}: {value}
            
          ))}
        
      

      
        By desc value
        
          {Object.entries(pairs).map(([key, value]) => (
            
              {key}: {invertString(value)}
            
          ))}
        
      
    
JSXG:

    
      if (user.loggedIn) {
        yield  user.loggedIn = false}
              >
                Logout
              
      } else {
        yield  user.loggedIn = true}>
                Login
              
      }
    

    
      
        By key
        
          for (const [key, value] of Object.entries(pairs)) {
            yield 
                    {key}: {value}
                  
          }
        
      

      
        By desc value
        
          for (const [key, value] of Object.entries(pairs)) {
            yield 
                    {key}: {invertString(value)}
                  
          }
        
      
    
Edit:

Come to think of it, I think it may have been ... or even (:O gasp) ....

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

#80
This looks cool, love the API.

I don't any support for lifecycle hooks (eg. something like onMount when the returned node will be attached to the document) in the component api. In absense of those, I imagine integrating with vanillajs libraries will be difficult (eg. codemirror, slickgrid etc.) Curious what your thoughts in the matter are.

Post reply on HN