I feel like this is one of the under-appreciated reasons why the web is taking over desktop apps. It's so much easier to build a web app that runs with native extensions than it is to build a native app with almost any toolkit. Even if you only target a single platform (say, macOS, and excluding Windows/iOS/Android development), is there a single platform's GUI toolkit that can stack up to what you get in 10 minutes of setting up an electron app?
That's certainly true, but consider how many tens (hundreds?) of billions of dollars were spent until web development reached the state it is in today. And how many dead ends had to be explored before we had things like browser dev tools with integrated support for React. Think of all the frameworks that no one uses anymore, the abandoned bundlers, templates, entire languages like CoffeeScript, the list goes on and on.
The amount of brainpower invested in the web platform dwarfs what any native toolkit has been given. No wonder it's so good; it would have been a crazy waste of resources otherwise. I'm sure native toolkits would be just as user-friendly, or even better, if they had such lavish resources dedicated to improving them.
You also want to mention an additional reason: native toolkits have to be tested multiple times; once for windows, once for macos, once again for Linux and whatever else you want to support. Even if you get QT deployed for a Mac version, there's still no guarantee they look the same on Windows. Each platform has its own quirk.
With fewer developers working with these toolkits, we see less adoption, more issues, etc.
> I feel like this is one of the under-appreciated reasons why the web is taking over desktop apps. It's so much easier to build a web app that runs with native extensions than it is to build a native app with almost any toolkit.
I disagree. Microsoft's WPF to me feels like GUI development done right. Designing UI components is a first-class citizen and even has WYSIWYG support, rendering data with observers is also a first class citizen with it's data binding feature, styling is also supported right out of the box, etc.
In theory frameworks like React sound nice, but once developers start to pour hooks left and right and add conditionals and move service client calls into trees then at least to me it quickly becomes an unreadable and unmaintainable mess.
Qt is pretty good to setup a widget tree, but it's model-view implementation feels broken and not thought through, specially with tables and trees.
> Microsoft's WPF to me feels like GUI development done right
I really do enjoy working with WPF. I just wish Microsoft would give us clear directions on the state of UI development on Windows, whether WPF has a future or not. MAUI doesn't feel like it yet because it feels mobile-first.
It's just Darwinism at work. OS vendors had *decades* to get their shit together and come up with a proper application model and UI system that's both easy to use and works across platforms. But to them, vendor lock-in was always more important, no wonder that application developers turned their back and found a solution that works better for them.
I see your point but I don’t know if I agree with your conclusion. Browser stuff is popular because we have been in a local minimum, where people (consumers) don’t want to pay for software. Native software did exist but only the big guys found success, ie Microsoft, and that was often because of the enterprise space. With the browser, networked applications came to the foreground, and also a sneaky way to make money which was trading the apps/services for their data. If you follow the money, this is why browser tools have gotten where they are. In the meanwhile, it’s not like native hasn’t been doing anything. There is the entire mobile space that cropped up in the meanwhile and it makes some people a lot of money. Also, most native tools and apps are actually miles better in some ways, eg developing apps for iOS, but not many developers know because the world (read: money) has become web in the meanwhile.
This probably won’t last btw. There is already backlash, people will start realizing that simply payinh for what you value is essentially a more direct way of voting for how you want the world to be, and business/technology will continue to follow the money.
Maybe a universal app container, like the web, but with native-like OS integrations will be the future, especially with future resource heavy technology on the horizon, like ML and AR/VR. But who knows?
Anyways, it’s not because os vendors don’t have their shit together. It’s because computing is still nascent and consumers have been cheap, so the revolution was funded elsewhere and that will of course change.
xcode and swiftui is getting close. You can hover over visual elements and see the code, and vice versa. You can render the UI and modify layout and styles without compiling and launching a new instance of the app.
> Even if you only target a single platform (say, macOS, and excluding Windows/iOS/Android development), is there a single platform's GUI toolkit that can stack up to what you get in 10 minutes of setting up an electron app?
20 years old copy of Borland Delphi running on windows 95 machine will do that.
So it's the vision of a single person and another UI library is being born.
I'm being sceptical at this, cause it looks like the same problem with JS and all the frameworks: I can't find anything that has all the features I want, so I start a new one, which potentially never becomes stable.
I'm not a Rust developer (yet) and have a background in PHP and JS, so I'm glad if some vets can elaborate on the GUI problem with other programming languages.
I've recently been having some success with a fail-fast version of this. Quick example: I wanted a utility component library for React, and none of the ones I looked at seemed promising. So I built my own, focusing exclusively on the consumer API and seeing what was possible. I pretty quickly ruled that my dream API wasn't possible, but I figured out why and what trade offs were going into it. Then I want back to the available libraries with a much better understanding of the underlying problems, and identified one that most closely resembled what I thought was precisely what I wanted. This approach has worked for several of the dependencies I've adopted lately and I have found that I now spend a lot less time fighting with my dependencies because I'm trying to pigeonhole them into a place where they can't fit.
I think what's interesting here is that the author is trying to build a foundational component upon which other developers can leverage. The author is trying to build something that other GUIs will want to integrate (e.g. Druid and Xilem).
And I think it's fair for someone to put together a proof of concept as a research proposal. They may not make it far in and of itself, but it may become an inspiration for someone else.
GUI crate maintainers have expressed interest in AccessKit; so far three crates have started using it (egui, rui, iced in a PR).
This suggests to me that these maintainers are interested in the idea of pooling work and that they're willing to use other people's work instead of NIH-ing their own library. (Though that doesn't mean Masonry is what anybody will settle on.)
> I can't find anything that has all the features I want, so I start a new one, which potentially never becomes stable
The "potentially never stable" part is fair to worry about, but I disagree with the "start a new one" part.
While I do want to work on another UI library (Panoramix), this isn't what this post announces. The goal of Masonry is to promote code reuse. In my ideal scenarios, other libraries such as Xilem, Iced, SlintUI, etc... might come to rely on Masonry as their backend.
In fact, the "xkcd 927" problem is why I started Masonry in the first place: because I saw there were a lot of Rust GUI frameworks, but there was no crate that gave you a base to build a GUI framework from.
Well, these announcement threads are a good example of Cunningham's Law! I had never heard about Gammaray before.
I think this is an instance of "the future is already here, but it's unevenly distributed". All the tools I talk about in this post already exist in one way or another. Browser devtools already exist, rr and redux-replay already exist, pernosco already exists, etc.
But a lot of developers haven't heard about them (eg I suspect most Qt developers haven't heard of Gammaray), or can't use them for their specific use-case. And in the case of Rust UI, lots of greenfield frameworks are being developed that don't have these tools by default.
So Masonry isn't aiming to somehow be better than every existing desktop GUI framework. It's aiming to help Rust framework developers include these tools by default, so that developers always know to reach for them.
Same for GTK; settting `GTK_DEBUG=interactive` in the environment before running the app (I think you have to set a gsettings key somewhere first as well) brings up a separate window with your application that lets you inspect the UI.
I wonder how common these things are, though, in other toolkits.
> Side note, but the "browser dev tools but for Qt" exists, it is called Gammaray.
Also, accessibility tools like Microsoft's inspect[1] already allow people to see an app's widget tree.
With Qt it's also trivial to put together a tree view that renders your app's widget tree.
Qt also provides infrastructure to unit test widgets.[2]
Qt also uses UI form files to allow WYSIWYG access to their UI components.
From reading the article, I was left with the impression that the author's struggles with a Qt codebase was that he had little to no experience with desktop development in general and Qt in particular, and experienced issues trying to get his bearings.
There are tons of them developed during the last 25 years.
When I see posts like this, it only shows how little current generations know about native tooling, mostly because they only focus on FOSS stuff on GNU/Linux instead of what is available on other systems, or eventually paid for tooling.
I've went looking for these myself. While they certainly might exist, the literature is not easy to find for those in the FOSS community.
The other issue is that most people are looking for cross-platform options outside the C/C++ ecosystem. While I understand the tradeoffs for cross-platform UX, the truth is that it's only the giant amount of money placed into browser development that has made it even remotely productive.
(Independently, I think we would be better off with a reinvention of the Java Web Start idea that disposes with the bad foundation we have for web applications, but that's a different blog post.)
I don't even need it to be interactive: all I want is a UI-oriented DSL with live-preview. Which is why I personally think SlintUI is currently way ahead of the competition.
The author basically suggests a DSL themselves despite this framework's UI being Rust constructs, as they note the importance of fast iteration and then say that because of Rust's slow compile times it's probably not the ideal language.
A DSL provides more than fast iteration too. It also encourages good code quality by forcing you to separate the app's UI from the rest of the logic. And complete language control means that a true DSL with its own syntax will always be more readable than anything you can embed in Rust's.
> It also encourages good code quality by forcing you to separate the app's UI from the rest of the logic.
This concept of separation is always interesting to me.
In the 1990s, when MVC was first conceptualized, a GUI was (a) native (b) playing the dual role of both View and Controller. It is quite hard (not impossible, but hard) to separate the app's UI from "the rest of the logic".
Consider trivial interactions (i.e. the Controller side of the UI element) like drags. What does a drag do? How do you conceptualize limits on the motion? How do you convey semantics between the Model and the Controller? How do you handle the differences between clicks (essentially drags with no movement) and actual drags? How does the Controller handle both axes? Gestures? etc.
Remember: the UI is the thing that receives input events from <somewhere, and in its capacity as the Controller, alters the Model state, which in turn causes changes in the appearance of the UI (as the View). This then creates additional issues if changes to the Model state are expensive (i.e. the Model contains/controls heavyweight resources), and thus Controller interaction must first work on a "pseudo-model" which is also represented by the View aspect of the UI, until the interaction is complete, at which time, the Controller propagates the actual change(s) into the "real" Model.
Yes, quite a bit of this has been revised/extended/expanded (e.g. Microsoft's View-Model concept), but the basic issues remain, and make the kind of separation you're thinking about hard to do in practice for all but basic data presentation applications.
Most webdev stuff that I've seen completely fuzzes the distinction between View and Controller, or changes it into something quite different from the original concept in MVC.
I used to work downstairs from one of the UW CS&E faculty who helped push MVC, and I would disagree quite harshly.
The problem, such as it is, is that the original examples they tended to use involved systems where the View and Controller were physically separate systems. Consider a medical scan data viewer with (a) a screen (b) a series of controllers to manipulate what appears on the screen.
In this context, all 3 of MVC are clearly identifiable and easy to talk about and understand.
But as it got applied to GUIs where there are no distinct physical controllers and all the interaction occurs intimately tied to the View (i.e. what's on the screen), it is harder to find the boundaries between the V and C parts (and to some extent even the M).
On a more serious note, would be interesting to see an app builder inspired by the UI and Blueprint editors of UE but tailored for apps rather than games.
I've heard people using the Godot Engine to make complex UI applications. So I've tried myself writing a simple app (it required multiple windows support which was added in Godot 4 beta), and the experience was really solid. It has its own slot/signal system like Qt but because it's much more well integrated into the language/editor. The node system in Godot is similar to the DOM, and editing layout was much easier than expected. (Compared to Unity's UI system which was built on top of a component system and is more finicky to use because of this. And no and I don't want to talk about UIElements, it's unfinished and unusable in its current state). And most important you don't need to wait for C++/MOC compiler to build, because of the scripting langauge (GDScript) changes can be tested instantaneously.
Unreal Engine might be a bit overkill since it has too many dependencies built in (you don't need a state-of-the-art 3D renderer and physics engine for UI). Godot is much more lightweight than that (about 40~50 MB from my tests, at least better than Electron), but some might still think that's too much though.
uh there are a bunch of those, locofy, teleportHQ, etc.
They are okay-ish, if you know the rules of the target code system/platform. (Ie. if you know React, and so you already create components in the UI builder.)
So basically my big problem is that these UI builders don't force/encourage the conventions that result in nice code.
The potential is there, of course, maybe even throwing a chatGPT-like AI in the loop can help with recognizing what the user wants and emitting and maintaining the resulting code base.
Question... What happened with Interface Builder on Mac OS X? What made it not successful and why did it end up falling out of popularity? That was one of the features that was championed when Mac OS X was just starting and it was going to be the future of all GUI development on OS X. (Honestly GUIs have gone steadily downhill on OS X for quite some time as it's being overtaken by GUIs that look like they're designed for the iPhone.)
With swiftui previews you can press the + plus icon in the top right and get the drag and drop component builder[0]. On the right side bar you also get a bunch of ui builder options that will generate code for you. [1]
Yes! It's incredible how many steps backwards the UX world has taken in the last 20 years, and all we've got from it is some shaky sort of platform independence.
Shaky? Full-blown professional tools like Figma running almost flawlessly on 5 different operating systems is not shaky. We've never had a better developer story before.
This sounds great, and yes is exactly the sort of GUI framework I'd want to use; I've also had the displeasure of using Qt/QML (though not at such scale/for as long)).
... But I can pretty much do this today with Tauri? The missing bit here IMO is why we need to rebuild webdev-like tooling in a Rust-only framework rather than just use it.
Everything has tradeoffs; web-based UIs have a performance cost (not a prohibitive one for most things, but a cost is a cost). So it's not a bad thing to have native options
But you're definitely right that devex is one of the web's main strengths. It's really hard to replicate that without a massive community like the one the web has; that's going to be a sticking point for any native framework (which if we're honest, are going to remain a niche going forward)
Even with cross-platform frameworks, there's a big fragmentation problem right now. And even if there weren't, native development as a whole is simply a smaller community these days
> It's really hard to replicate that without a massive community
It's not the size of the community. It's the use of interpreted languages and strong introspection and a (relatively) consistent platform called "the browser". That's what make devex so different to native.
Sure, the endless stream of new frameworks etc. also contributes to the difference, but it's not as fundamental IMO.
More seriously though, that's a fair question. Anything that isn't the web has a lot of catching up to do before it can compare to the web.
(Though browsers are increasingly relying on rust frameworks for low-level work, so there's some potential for code reuse.)
My gut feeling answer would be "because things built for the web have a tendency to fail for no reason, and things built in Rust have a tendency to work on the first try". I'd have a hard time backing up that gut feeling with hard numbers, but I think it's a shared one. Web techs tend to have all sort of legacy cruft and small papercuts and stuff. Mature Rust crates are easy to install, work immediately and have an intuitive API. My hope is to get to a point where developing Rust GUI is just easy, no papercuts.
how do things on the web fail for no reason? My experience is the exact opposite. The web's html is very lenient and if you html makes somewhat sense it will render your document.
If you're comparing legacy web code to new and modern rust crates of course it's not a fair comparison. just wait until the until the second wave of rust gui libs, it will be a similar pain of legacy code when the web industry went from Angular v1 to React. Legacy projects, outdated packages and brittle build processes, now with rust there will also be the added "benefit" of a more complicated programming language.
No, seriously, if I’m going to build something, then in general (not in all domains, but in most) I find it far more relaxing in Rust than in any other language I know. (I am biased by almost a decade of Rust being my preferred language, but I’ve continued to use JavaScript more often than Rust, with a fair bit of Python from time to time and a smattering of other languages; so Rust is hardly the only thing I work in.) It’s got comfortable and roughly-universally-accepted base tooling so that I’ll waste less time on scaffolding and initial decision-making than is the case in most (though certainly not all) languages, and then it’s just a whole lot more robust to develop in, with an excellent type system and semantics that removes many of the pain points in most other vaguely-similar (say, C-family) languages. Maintenance especially is delightful, particularly if you’re comparing it with web tech (which is the specific comparison being made).
It’s not all sunshine and roses, and the lack of things like browsers’ dev tools can certainly be painful, but Rust honestly is good enough to warrant serious consideration even in spaces where these difficulties apply.
PoignardAzur was speaking lightheartedly, but I honestly don’t think it’s an unreasonable general sentiment.
The web will not last forever. Better to build a foundation that is capable of bridging to the web if necessary than staking yet another UI layout engine atop a document markup syntax.
The conceptual foundations of something like this are extremely important.
If you stake the basic ideas of the framework on the DOM, then DOM details will become implementation details which will become details that clients will depend on. And you'll have just re-written React but with even more layers.
It needs to be thought about in terms of first principles, ala SICP. There are basic primitives to be defined that are the "ground," and then it is built up from there.
That is a very interesting viewpoint. I’m not a webaholic like a lot of the JS devs out there. It’s a shit platform. But I have no illusions about its lasting power. Why do you think the web stack is going to go away?
given ff safari(?) chrome and old edge all have Dev tools and node can attach to Chrome, is that specified well enough to use one of those with the framework?
Yeah I was thinking the same thing. Especially since many of these frameworks try to target the web via WASM, if you made that piece smooth you might not need a 1p solution for a simple and just leverage browsers for that piece (+ profiling and even maybe hot reloading).
