In my opinion, the best GUI approach is still JUCE. Every UI element is a C++ class with a drawing function. You create new UI elements by composing other elements to create another C++ class, for which the editor will auto-generate the source code. For buttons, you have a large if...else... area in the drawing function to handle different states like hover, pressed, active, disabled, etc. Behind the scenes, a thin drawing library will use Metal/OpenGL/DirectX as needed.
I find it refreshing that everything is imperative. You can put a breakpoint anywhere and you'll see when it gets called, with which parameters, by whom. You can also export intermediate rendering states to imdraw. Plus it's almost pixel-perfect (except for font antialiasing) on all platforms.
The XML variant being peddled here is, in my opinion, exactly what I usually try to avoid: framework-dependent magic. I'm 100% sure that 3 framework upgrades down the line, the layout will be slightly off. Because it was never you owning the layout, it was always you begging the framework for its consideration. The only thing that somewhat mitigates this issue with Electron is that it uses "old" technology. CSS isn't going to change much by itself anymore.
I haven’t tried JUCE yet but I miss the days where everything was a C++ class in Qt. Everyone clamours for a templating language but:
class MyButton extends QObject {
…
$button = new Button();
$button->color = “blue”;
$icon = new Svg();
$layout = new QtHorizontal();
$layout->push($icon, $button);
$this->layout = $layout;
…
}
This to me is much more readable than fiddling with stacked, embedded, and nested mustache/XML syntax split across files. Templating languages only really guarantee one unique thing about understanding the code: “Is my module embedded under the correct parent module?”
I have switched to JUCE as a total cross-platform GUI/high-performance general application development environment, having used it for 7 years in the audio realm I have attained that state, whatever it is, where I realize I can just use it for everything and it’ll be perfectly fine.
Doesn’t take too much CMake wrangling either, and once you’ve got at least one half-decent, clonable JUCE -> CI pipeline working, the horizon gets wider and wider ..
That said, I have to admit that I think more and more about how fun it’d be to just put all JUCE GUI code in a Lazarus’ish front-end, using LUA for that part, and having a decent half Lua/half C++ monstrosity for doing things ..
The splash screen is a condition for using JUCE for free under the AGPLv3 license, particularly when distributing open-source projects or plugins without purchasing a commercial license.
I've never heard of JUCE before, but from what I understand JUCE is more like the web platform itself (juce::Component is like DOM or canvas elements), while XMLUI is more appropriately compared to declarative UI systems built on top of JUCE (GUI Magic, JIVE, or VITRO).
Declarative and imperative UI approaches aren't mutually exclusive, and it's common for software to leverage both (e.g. SwiftUI and UIKit).
I've never used JUCE before but I agree that the imperative approach, while often larger in implementation, is usually very explicit about what is happening and allows full control. Declarative approaches always need escape hatches, and those escape hatches are usually tricky to open and pass through.
As a counterpoint, being primarily a web developer (although I did Windows desktop apps with Delphi in the 90s) I hard time doing UI with JUCE.
It never really clicked with me and I had a hard time really aligning things, with their Flexbox thing etc, how you set graphic values outside vs inside component classes, being sometimes confused how paint() vs resized() affect things etc.
Probably operator error but in the end I was happy to ditch it for the new WebView option in JUCE 8.
JUCE 8's WebView is an abomination that tarnishes an otherwise amazing framework.
Yes, coming from the web, JUCE' Flexbox and paint()/resize() semantics are going to be 'weird' - but thats the point. You have the power to decide when/how to update your GUI, frame by frame - and for high performance GUI's, this is vital.
These days it has to be said: you can get a LOT of your JUCE GUI work done for you by an LLM with great results.
Maybe but I actually got a ton of hallucination about the JUCE API with LLMs, as in they sometimes would just not produce workable code at all and invent functions repeatedly (endless infamous "you're right!").
My project is not a typical audio plugin so it's also why I was not benefiting as much about the graphic API as others may do.
But I'm not sure how the WebView is an abomination, it's actually a quite small API that works ... and is totally optional and didn't replace the original graphic API.
JUCE is also slow as heck and takes a lot of know-how to make performant. Notably, if you want any kind of real time animation or display, you don't do anything component based.
It also involves a custom C++ module system and build strategy that is hard to make fast and generally is impossible to use JUCE as a library, so you wind up recompiling it as a dependency an excessive number of times (which adds up in CI).
React itself was class based in the beginning, and that would have probably been a better model in the long run - it was a lot more code for sure, but less complexity.
This is definitely debatable. I grok the composable functions model quite well, and hooks let you separate logic out of components extremely well and intuitively once you understand the basics of React.
By comparison, I feel class component's promoted 'mile high' components where everything was inside of the class, which has many enormous drawbacks, one of the biggest being maintainability.
To this today though, I feel most people don't understand the simple rule of UI is the last mile concern. Developers still cram way too much into components rather than separating layers of concerns
It just works, in my experience, with Narrator on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. The graphical component editor lets you set stuff like labels and tab order and that's usually enough to make things work at least okay with a screen-reader. Getting things to work A+ requires more manual effort, such as implementing AccessibilityHandler for complex components. But the basic JUCE classes are usually much better than what you'd get from any "JavaScript inside WebView" GUI, precisely because you manually coordinate the presentation and the screenreader texts.
I've worked on Surge, which is (to my knowledge) the only fully accessible synthesizer. It uses Juce's a11y abilities to do this work, plus a whole lot of very thoughtful design. We have multiple blind users.
I find it refreshing that everything is imperative. You can put a breakpoint anywhere and you'll see when it gets called, with which parameters, by whom. You can also export intermediate rendering states to imdraw. Plus it's almost pixel-perfect (except for font antialiasing) on all platforms.
The XML variant being peddled here is, in my opinion, exactly what I usually try to avoid: framework-dependent magic. I'm 100% sure that 3 framework upgrades down the line, the layout will be slightly off. Because it was never you owning the layout, it was always you begging the framework for its consideration. The only thing that somewhat mitigates this issue with Electron is that it uses "old" technology. CSS isn't going to change much by itself anymore.