Hacker News Reader

Comment by felipefar | Hacker News Reader

I'm curious to hear your take on this: what's the advantage of following the virtual control tree approach compared to instead updating directly the controls that are displayed to the user?

View on HN

For complex scenarios (i.e. the user interacting with the UI while there are some long-running processes in the backround doing this, too), managing the state quickly gets unwiedly: You need to write callback code everywhere that carefully has to inspect the current status of all other activities and might then updates 10s of widgets accordingly.

With the reactive approach you are able to write a single rendering function that describes the interface for any given state and the framework takes care of the rest (when to call that function, what "input" to give it).

It's just way easier to wrap my head around this and after working with React it is hard to go back. Hence the experiment to see if something comparable could be done in Go.

I'm already convinced of the benefit of declarative GUIs over imperative ones. To be clearer, what I mean by declarative GUIs is ones where I can specify that UI elements should be bound to certain values in the memory of my program, so that they don't have to be changed explicitly by imperative code. Ex.:

TextBox { Text: app.currentUser.name }

Instead of having to call setText on that TextBox.

What I'm still missing is why it has to involve a virtual tree being maintained and synchronized with the real GUI tree. The UI engine could implement the above binding by instantiating for the user a callback trigerred when the bound property changes and changing precisely the value currently shown on the screen. Hence, the UI engine is in charge of the callbacks, which keeps the user unburdened by callbacks.

The virtual component tree is needed as there is no 1:1 mapping of components to widgets.

Using the virtual tree, you are able to build components which dynamically change the rendered subtree based on the current state.

SolidJS works pretty much as you describe, and it’s great. It feels like the best bits of React, but object lifetimes and re-rendering and the real UI behavior are all much easier to understand.

(Or at least, to paraphrase Joseph Heller, “it’s intuitive once you get your head around it”)

If I'm not mistaken what you describe is pretty much exactly the approach in .NET app development (WPF, MAUI, ...) with C# for the logic and XAML for declarative UI including Binding and it works well and performantly so.

This is exactly how the data binding APIs in Fyne (another Go GUI toolkit) work. And it's also an optional feature, so if you want to handle things by registering callbacks and calling setters yourself you can do that too.

Thanks for making this library, but IMHO these are distinct concerns. One can leverage a state machine or an ECS library for complex state management. Only basic data binding can be a framework capability if needed.

The web had a lack of options for state management and hence React coupled the two.

Reply on news.ycombinator.com