[felipefar]

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.

[iainmerrick]

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

[da_rob]

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.

[jdthedisciple]

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.

[dweymouth]

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.