HN Explorer

9 comments

[ 3.4 ms ] story [ 22.8 ms ] thread
stuaxo
Certainly much nicer than the traditional way of doing this :)
wallacoloo
So this recreates the entire scene graph whenever the UI needs to be re-rendered? What happens when you use this in a complex application with lots of different nodes that needs to be updated frequently? Think a midi tracker / DAW / video editor, where it's common to have a vertical bar that moves across the screen indicating the current section of audio/video being played. Is this still suitable for that sort of application? I get that it's doing diffs and not actually re-rendering everything, but how heavy is the call to create each node?
samtoday
The Node class (used in render) is just a tuple, so it is very fast. It riffs it to ensure minimal changes.
xenonite
For a quite similar approach of observing/binding variables to GUI objects, have a look at Qt/QML.
snuxoll
GObject/GTK also have GBinding's, which are exposed in PyGObject. Most of the remaining problems stem from things like List/Tree components that use complex models, though providing a derived model class that is backed by a reactive data store would handle that nicely.
netforay
This is similar to what React.js or Vue.js does on the browser. I always thought of this, very nice to see it running. I worry about the following.. 1. How we do complex objects like Trees and Tables? 2. How efficient are these Native nodes over DOM nodes in Browser?

I always wonder between Native vs DOM.