(2024-09-23) In 2024, desktop GUI development is still pretty wild ------------------------------------------------------------------ Throughout the recent, like, 10 years already, there is a popular question: why are the current-gen desktop GUI application developers so lazy that they keep choosing humongous browser-based frameworks like Electron to implement the GUIs, as opposed to using traditional native toolkits consuming much less resources? Well, I think I know several sad but true answers to this question now. And the first and the most obvious one is: Web browsers work and everything else doesn't. Let's consider a simple use case inspired by my StreamGoose chat UI which is in no way any complex: a scrollable vertical list of messages that are dynamically appended and can have various height, which is solely determined by the width of the list block itself and the length of their contents. That's it. Any Web browser does this naturally by design. Now, try and find a desktop-native GUI framework, preferably a cross-platform one, that would allow you to do just that. I tried doing this for Go, which is a rather popular programming language and has a lot of bindings to a lot of graphical stuff. Even the well-renowned Fyne framework doesn't allow you to have dynamic list item height, you'll have to calculate it for each item individually, which is nuts, considering you can resize the window and also have some images inside the message. The only library that **kinda** worked in this scenario was Gio UI ([1]), but it's far from any desktop-native experience because all of those "immediate mode UI" toolkits are built on top of OpenGL or similar renderers, and when you have to use an engine designed for 3D gaming just to be able to draw simple GUI widgets, I think there's something inherently wrong with that. Some GUI libraries (e.g. giu and Cogent Core) didn't compile at all on my Alpine because of some dependencies not working with musl, great... And, of course, Go's libui binding generally lacks scrolling support just like its C counterpart. Unfortunately, the problems don't stop there. Returning to Fyne, there also is no straightforward way to set a different color to a label or even a part of the rich text element. The developers say it's a part of "enforcing UI consistency", but what if e.g. coloring individual Twitch usernames according to their preferences is a necessary part of application design? As such, you'll have to use cumbersome workarounds where you really shouldn't. If I color a label, I fully know what I'm doing and why. My take on it is: stop treating developers like idiots and don't restrict their freedom to do stuff. Otherwise, the use cases of your toolkit won't go far beyond what you can see on the Fyne's app gallery page ([2]). Because yes, for anything slightly more advanced, you'll have to become MUCH more verbose. And no, it's not a new thing, desktop toolkits have been like this forever. MFC, VCL, GTK, Qt... All of them invented a bunch of problems that you absolutely must solve instead of thinking about the UI itself. In terms of development complexity and boilerplate code amount, none of them progressed a lot compared to what bare WinAPI/Xaw/etc could offer. This is because all of them were created from the perspective of those who code, not those who compose. Web browsers, on the other hand, became too atrractive despite all their flaws because they could offer something radically different: you are no longer constrained to a predefined set of layouts, themes, fonts etc, you get fluid text and widget flow basically for free, and, once written correctly, your GUI will work virtually anywhere, from a 2.5-inch KaiOS phone to a giant iMac. In fact, Web UIs became notoriously bad and slow just because most devs stopped knowing how to write them correctly and started stacking a lot of useless framework bloatware on top of them, not because the underlying technology is evil or something. Speaking of which, my second answer to the initial question is: yes, developers are lazy, they usually don't have time and/or budget to rewrite the same UI for different target platforms, or, in case of cross-platform frameworks like Qt and Fyne, to fight any quirks they might find in a particular deployment. With HTML5, as long as you adhere to the "lowest common denominator" of Web standards, you're generally fine on any platform. With true desktop GUI, it's not so obvious, and someone might eventually catch some bug that you can't reproduce on your own system. Go-based applications are generally less susceptible to platform-dependent bugs, because they usually bundle as much stuff as possible inside the binary, but that brings another problem to the table: a Fyne hello-world, compiled in release mode, weighs about 22 MB (18 if you exclude the built-in emoji font), and even a barebones Gio UI application is about 7MB large. Of course, any of this is nowhere near the 90 to 170 megs of full-bundled Web-based applications, but in that case you always have an option to offer the user a headless version and to connect with an existing Web browser to it (I even have such a build option for StreamGoose). Anyway, I know that storage space is not a huge issue these days and that most of the stuff occupying that space is not binaries themselves, but OTOH I am old enough to remember self-contained complex UI programs taking up much less than a single 3.5" floppy, so... what happened? Alright, enough of this rant. What I'm trying to get to is: don't yell at those who chose Web for desktop GUI, at least without providing any **viable** alternatives. They chose it simply because everything else they could hear about just sucks at being a good tool for their purposes. This is why we also keep hearing that desktop is dying on the mass consumer market: no one actually wants to write for it. In order to prevent this, we need a really well thought out, close to native, easy to use, lightweight, accessible and cross-platform GUI toolkit. As soon as we find one, things are going to change for the better. --- Luxferre --- [1]: https://gioui.org/ [2]: https://apps.fyne.io/all