Rust cross-platform GPUI components
github.com
github.com
The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell.
UPDATE: This honestly looks incredible and makes huge strides in the Rust UI landscape. You can run an impressive widget gallery app here showing all their components:
https://github.com/longbridge/gpui-component/tree/main/crate...
Just "cargo run --release"
I think part of the issue is that they're still changing so much as we speak. But there's real momentum here and n=1 but I've been able to build incredibly rich, enterprise-ready UI with Rust today.
Which UI crate did you use? The word "enterprise" caught my eye. So far I haven't found a Rust UI crate that I found rich enough, so I'm curious your experience.
Thanks for the reply.
In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"
FWIW, you wrote that you actually HAVE done so, not just that you think you could:
"but I've been able to build incredibly rich, enterprise-ready UI with Rust today."
Unless one has actually done so, and maintained/extended over a period of time, and not solo but with others, I don't know that one can be certain that a UI toolkit is good enough; certainly, it would be hard to know what surprising edges and ergonomics there are to consider in one's evaluation.
I hear your point, but it's important to note I'm not making those claims and I don't think all of that needs to be true for it to be some value of "enterprise-ready". You and I may disagree on the meaning of that term, and that's fine.
Pain points were learning to think in The Elm Architecture early on and creating very complex custom widgets of my own (think a spreadsheet editor, for example)
I made some tiny apps available on my github as I was learning Rust and the library. None really meet the enterprise grade hurdle but show some of what's possible with little code. If you spend a little while longer you can make them much more polished, obviously. I kept them "unpolished" so they would be even easier for beginners to follow
I do share screenshots and screen recordings every now and then in the iced Discord but I've so far refrained from posting about it on HN which is a much bigger audience
I suppose the best description of the UI is a mashup of VSCode and Figma
I have a feeling iced would work similarly well but the documentation situation wasn't as good last I checked.
And if you're on Discord, the community is 10/10. I'm there all the time and always helping newcomers, and so are many others.
> https://github.com/longbridge/gpui-component/tree/main/crate...
> Just "cargo run --release"
Very impressive! Only thing I am concerned over is that it uses around 900 dependencies. But I don't know whether it much for GUI applications.
The other thing you can do (which is popular in the Bevy community) is to compiile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.
[0]: https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...
I'm curious as to what this means exactly. Are you saying keep the UI stuff in a separate crate from rest of app or ???. And just a separate or an actual dynlib? (wouldn't that imply C ABI? would make it a pain to interface with it)
It doesn't necessarily require C ABI. Rust doesn't make any guarantees about stability of the Rust ABI. But if you compile the app and the dynlib with the same compiler version then it works in practice (and IIRC there are enough things relying on this that this is unlikely to break in future).
That does mean you need to recompile the dynlib when you upgrade the compiler, but that is probably infrequent enough not to be a huge issue. Certainly if your aim is fast-recompiles in response to e.g. ui style changes then it ought to work.
--
A note on the sort of Rust compile times I see for a TodoMVC app using my Rust UI framework (412 dependencies):
- A clean release build (-O3) is 1m 01s
- An incremental (-03) rebuild is 1.7s
- A clean debug build (-O0) is 35s
- An incremental debug build (-O0) is 1s
That's on a 2021 MacBook M1 Pro which is fairly fast, but I hear the M4 machines are ~twice as fast. And that's also without any fancy tricks.
However, I don't see what advantage this gives. You are going to specify that dependency in your Cargo.toml just like any statically linked crate. Anything that would invalidate the cache for a static crate would invalidate it for a dynamic linked crate. Iow, it seems like separate crates are the magic here, not the linking type. What am I missing?
Thanks for the build stats. Those are helpful. I have an M1 Max currently.
UPDATE: Good points below. As a dynlib it would create a boundary for sure (no LTO, etc.). Worth playing with, thx.
I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental.
See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs <2s with newers ones.
There are few strategies for dealing with this:
1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, the new built-in ld64 is pretty good. Not sure what the state is on Windows: possibly lld is best?
2. Is dynamic linking as above. This seems to be faster even though the dynamic links need to resolved at runtime. I presume because at least the links wholly within the dynlib don't need to be resolved.
3. Is tools like Subsecond (https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...) which effectively implement incremental linking by diffing the symbols in object files.
(dioxus-7-rc.3)
It usually only works when reordering elements, or changing static values (styles, attributes, etc).
Which, to be fair, does speed things up a lot when tinkering with small details.
But 70%+ or so of my changes still result in recompiles.
I've been able to get the hotpatching to work for use cases like "extract some UI code" into a new component that didn't exist before.
Note that the hotpatching is not enabled by default, you have to specify --hotpatch when running dx
I indeed was not enabling it.
I'll give it a try!
Yeah, although I would define "reversible computing" as how to deterministically undo some computation(s)/effect(s) etc without recording the control-flow and I do not like the notation of "time-reversibility", because distinguishing between "reversible computing with known timings" and "reversible computing with unknown timings" becomes very confusing. So I'd phrase it somewhat differently, but did not come up with better naming yet. Context: https://en.wikipedia.org/wiki/Reversible_computing and https://en.wikipedia.org/wiki/Time_reversibility.
gpui itself is spun out of the zed editor, so I'd say it probably has more real-world usage than the majority of rust UI crates
I'd be very surprised to learn that any other Rust UI crate has more real-world usage than GPUI!
Source:
https://sequoiacap.com/article/partnering-with-zed-the-ai-po...
I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?
The more salient metrics would be things like how many people know how to use the framework, the variety of use-cases its good for solving, how easy it is to hire or get help with it, etc. As for Druid, Druid is already officially unmaintained, its core developer having moved on to work on Xilem instead. (my experience, for the record, was positive, I very much enjoyed working with Druid.)
I actually tried to create a UI kit using zed's code for a personal project, but gave up.
nice to see I was not the only one with the idea and it can get some usage now. The example app looks awesome.
Are you trying to tell something more logical? Does the "Rust gamedev scene" affect the technical merits of libraries?
Bevy gets all the hype, but Fyrox has more maturity in a lot of surface area.
Bevy is led by a large team, and the leadership is ex-Google.
Fyrox is one solo Russian developer with 10x engineering output.
Bevy is ECS, Fyrox isn't.
Bevy does a great job marketing itself, it has a foundation and a large community, and people are excited to try and use ECS.
And to be fair, not every great engineer is a great writer, artist, composer, or any other role one might like to have on board for making a game.
Nobody makes games in Bevy though, Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games. Even the biggest title out there, Tiny Glade, is just a level editor with precisely zero gameplay features. Bevy's "popularity" (on social media, not among game developers) is entirely hype-driven by people that do not actually make games at all.
This stance is not necessarily wrong - life is short, after all, and not every cup of tea has to be drunk from - but it does make finding useful criticism in a haystack of generic talking points rather difficult.
The entire raison d'être of Bevy and the reason it is built how it is is that the ECS eliminates that. If your Bevy code contains something that looks like that, you are using it very wrong. You put the data in the ECS, and any gameplay code goes into some system that uses the queries to pull the data it needs out of it. If you need something like a backreference, you don't add one in an unholy tower of refcells, you just use a different query.
If you wanted to argue that a soup of mutually referencing objects is easier to deal with than having to use a query system, I'd disagree, but you'd have a valid argument. What you posted above just highlights that you don't know much about bevy.
Obviously not true, latest Bevy Jam has ~100 submissions! They might not be the games you were thinking about, but they're games nonetheless.
Beyond the game jams there are definitively people making games with Bevy too, but I don't think anyone of them gone mainstream (yet?) but it's a bit harsh to say no one is making games with Bevy when that's clearly not true.
It takes a long time for a game engine to be ready to create the kind of experiences you're probably thinking about, and even if everything goes great with Bevy in the future, it's still probably years rather than months until any big studio will think of start using it for something important.
With that said, people are for sure making games in Bevy even if the experience is non-optimal. Search on GitHub for "bevy" and sort by latest update and you get a snapshot of the projects that are on GitHub, then imagine there is a magnitude more people working privately.
https://steamdb.info/stats/gameratings/2025/?min_reviews=500...
For me the experience is completely the opposite. ECS as a pattern lets me build way larger games with more complicated and interesting gameplay than I could build before without ECS. It's something about about easy it makes to create de-coupled functions and being able to easily put things under automatic testing that makes the whole process so much smoother. Before moving to Bevy I mostly used Unreal Engine and on two projects Unity, FWIW.
> I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh
I don't think it's harsh at all, I'd do the same if I was trying to build mainstream games, and I think many other peoples do so to.
But that's also very different than "Nobody makes games in Bevy though" which is what you said at first, which is a lot less charitable than what you wrote in your comment now. I understand it's an exaggeration, but it reads as you're sour about it, rather than being interested in a conversation about it.
And again, I am not sure what exactly people are expecting of a game engine that started development in 2019. Development of Tiny Glade itself started less than three years after Bevy's first commit, which was an obvious factor in Pounce Light building a custom renderer.
If your criteria for "made with Bevy" is "every single system in the game must be from Bevy", then sure, you won't find a single Bevy game in existence. But you will also find a lot fewer Unity and Unreal games than you think.
0. https://80.lv/articles/exclusive-tiny-glade-developers-discu...
I would agree with you that bevy is not fit for making a commercial game. but not because its not capable. Its just NEW. we are only now starting to see commercial games come out with godot and thats 11 years old. bevy came out what, late 2021? give it some time. It still needs more workflow tools, a level editor stable documentation and a bunch of other things.
It will get there. it just takes time.
However, it doesn't even use Bevy's renderer, but their own: the devs mostly just care about its ECS. So it definitely isn't the showcase Bevy is looking for.
But the lineup of high-quality games in production with Bevy just never stops to impress me. I'm always surprised by the new cool stuff they're making every time I take a peek at their community. Yes, most of them are not finished yet, but the engine is still young so that's understandable (gamedev can take years).
On the other hand, I'm still not really seeing any games being made in Fyrox despite it being a few months older than Bevy. Huge respect to the dev though, he's making great stuff.
But if I ever need to pick a pure Rust game engine at all, it's def going to be Bevy.
The smell for me is if the library is designed based on a plan, or attempting to be X ecosystem in Rust instead of built around one or more practical piece of software, and evolving to meet the needs of these softwares.
With that in mind: I adore EGUI. I hadn't heared of GPGUI before, but because of its origin as being purpose built for the Zed editor, this immediately gives it credibility, and I'm excited about it!
Doesn't mean bevy is better or anything, just that because it's so different people tend to flock to it.
(disclaimer: I think bitcoin is dumb, but the market disagrees)
I believe that market is quite controversial. Most people know that bitcoin is a bit dump, but they buy it regardless because they believe they profit from it when they do that as part of larger group. A very interesting social experiment with the mix of market manipulation. It is less about stability, independence or usability of the currency, but more about the opportunity of profit.
Also, Longbridge, who seem to be using this GPUI component library for their Longbridge Pro [1] app, look to me like a regular online brokerage company. What is your issue with that?
BTW, I am not associated with zed in any way.
React is unfortunately becoming more foundational than this project, and with it maintained by a company that was involved in the Rohingya genocide in Myanmar, the Cambridge Analytica scandal and so on.
This makes crypto / trading companies look like angels compared to what Facebook has done even though they made and open sourced React.
To that end, I don't see anything morally wrong with the former camp of companies supporting open source, (trading/crypto) since they didn't participate and amplify an actual genocide.
What do you run your browser as?
Low.
What's the likelihood of someone entering your house if it's unlocked?
Also low, and yet you lock it.
No, you would want to draw for Wayland or X. GTK and Qt themselves don't burden with importing each-other to work, for example.
My guess is that they import GTK only to get a title bar on GNOME, as GNOME forces applications to render their own. They could go custom and cut the dependency but it never looks quite right when apps do that.
This is literally what the GNOME devs advocate: that each application draw their own borders and titles. You might consider that it doesn't look quite right, but that's the design choice they're going with.
Usually, I'd understand if you're lazy and can't be bothered and just pull in some dependency to do it for you, but if you're implementing a toolkit, this is the kind of thing that is SHOULD provide.
A few big dependencies each have a team and a reputation that has earned trust and established release process and standards. If there's a serious problem in a small part of a big dependency, there are a few trusted maintainers of the big dependency who can be reached and can resolve it.
The theory of small dependencies was a good theory, 10 years ago when js devs using NPM started the trend of making them "as small as possible". But it really seems like the emergent pattern is the opposite of what is claimed. These JS and Rust projects end up taking longer to build and resulting in bigger outputs. Instead of a couple of "huge" 200KB dependencies, you end up with _thousands_ of 1KB dependencies including different versions and alternative implementations, you end up with megabytes of "accidental" code you don't really need.
And we can reason about why. In an ecosystem where something has 1 to 3 large deps, well sometimes a dependency pulls in another sub-dependency with code you don't need. But in an ecosystem where something has 10 to 100 deps, this still happens, but 50x more overall. It's a exponential trend: you have 3 big deps that each have 2 big deps that each have 1 big dep, vs you have 20 small deps that each have 15 small deps that each have 10 small deps.
One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow.
Secondarily this comparison table has several problems when it comes to Qt.
* Their license is dual license LGPL *and* commercial.
* Minimum binary size is definitely not 20MB but less. In general your apps distribution size depends on which features of the toolkit you're using.
* Comparing "Syntax Highlighting" makes no sense... QSyntaxHighligther is an interface by which you can add your own syntax highlighting to any QDocument. You're welcome to use reg exps, parsers (such as tree-sitter) or whatever you want there.
* QRichText supports markdown such as HTML.You can make use of Figma integration for something similar to Qt Design Studio.
Too many folks nowadays don't seem to fully understand how powerful GUI designers for native code used to be.
You always get some arguments about pixel perfect positioning, completly ignoring the fact most of them had layout managers available, even VB pre-VB.NET (yes Windows Forms does support layout managers).
Don't want to pay upstream? Also don't get to charge money.
Want to pay up stream? Another license can be arranged where both parties get to earn money.
The reason why it's not possible to include GPLv3-only code in a GPLv3-or-later codebase is that the latter is more permissive, allowing the FSF to release an updated version of the GPL.
They won't make GPLv4 any less copyleft and more permissive than GPLv3, if they ever do make one. At worst, the GPLv4 will cause some commercial user of the code to be even more inconvenienced.
But to be fair to Slint, they do have a free proprietary license which can be used for developing proprietary applications as long as it’s not considers in the “embedded” space.
I am not asking them to remove GPLv3-only and replace it with MIT, I am asking them to use GPLv3-or-later.
In my experience that point is absolutely correct. Qt is good but big. You usually end up with 30-40MB of it.
Core, Gui, QML, Widget are 8MB each. For a Hello World you need 3 of those. Maybe 2.
Yes you could build Qt yourself with various flags, or possibly do a static build with LTO might help. But that's not the typical way Qt is used.
I just checked against Qt5 on ArchLinux. Core, GUI and Widget .so are all about 6mb each.
I concede that it's closer to 20mb after all but at the same time it's not a fair apples to apples comparison because those libraries provide you with so much more functionality than just the UI.
Comparing GPUI to Qt based only on what they offer gui-wise is fair, in my opinion. What QtCore provides is sugar over C++: the object model, the signal system, some data types, many helpers. But the thing is, all of those things are in Rust already. They're even in modern C++.
So comparing a Qt hello world that uses QtCore+QtGUI+(QtQML|QtWidget) to a Rust GPUI hello world seems fair to me. It's not like the author also counted QtNetwork, QtSQL, QtSVG, QtHTML, etc.
So yea I can understand why they aren’t a priority.
I accept that sometimes you need to some tricks with it and sometimes the layout in the preview is not the same you get at runtime which is annoying.
But in my UIs I use hundreds of widgets and I can't even begin to think about the useless effort required to write all the code by hand vs. spending seconds to drag and drop widgets into their place visually in the GUI editor...
You would probably want an xml/markup representation of component hierarchies, similar to other efforts, this can work with Rust with a macro interface that replaces the render hierarchy with the component structure format of this library. From there, you would need an application to hot-mount the same markup "live" as part of an interactive design tool.
In the end it wouldn't be much different than Glade, XAML or QT Designer. That said, you have to build a foundation before you can put solar panels on the roof.
Truth is Rust doesn't have, and will not have anytime soon anything comparable to Qt or VCL/LCL. No amount of GitHub starts and "made in Rust" disclaimers is going to change that.
That's the typical answer to these questions. Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.
Assuming the docs are correct, the UI controls seem ARIA compliant as long as you bother implementing the necessary descriptions and labels.
Because () are optional and a function call can look like this Button { stuff }. Meanwhile in dart, it's lines, and lines and indentation of 2 because it becomes a massive manuscript. I hope that makes more sense.
I must have a very different understanding of the word "arguably" than you. To me, it's arguable whether Swift itself is a viable cross-platform language today. SwiftUI, on the other hand, supports literally zero devices not manufactured by Apple.
Is it really arguable that when people say "cross plaform" when referring to a GUI framework, they aren't counting "both macOS and iOS, but not any of Windows, Android, Linux, web"? It might be accurate from an pedantic standpoint, but I have trouble imagining a context where someone would bother using that phrase as a qualifier if they understood it that broadly.
I welcome this, I want to write cross platform lightweight UI applications without going to C or C++.
GPUI is not "native OS widgets".
WPF is managed, only uses a bit of Win32 and DirectX 9, everything else is rendered by itself.
There are some details on what that exactly means, but I am on the go for lengthy comments.
Which itself is not used by Teams, which uses electron/WebView2, even though Teams is part of Office.
And let’s not forget about MAUI, which has its own components and UI library, which as far as I know is not used by anyone at Microsoft.
And I’ve heard from people at Microsoft that the future story of .NET UI framework is “Blazor WASM”. Is that considered native? Probably not. But I’d argue it should be considered “first party”.
Let’s be honest, Microsoft’s UI framework landscape is a mess.
Office framework would not exist without Win32, and usually it is made available on Win32, e.g. ribbon as common control.
Xamarin was never used at Microsoft, how to expect the rewrite to go any better. This acquisition was a mess, almost everything from Xamarin is gone.
Again, not a native API.
Blazor only matters for Web applications and PWAs, unless Windows turns into ChromeOS there is nothing native about it.
I give zero value to Blazor Hybrid, from my point of view it doesn't exist.
This is often a problem with Rust UI frameworks, they may look beautiful, but the moment accesibility becomes a requirement, the whole app needs to be scrapped and rewritten in something more mature.
This UI toolkit is based on GPUI library build by Zed editor team, and while they improve accessibility over time (like, improving contrast and stuff), it's opaque to screen readers.
At the moment if you want to have good accessibility story you should probably look at Slint or Qt (via cxx-qt, for example). And since System 76 picked up Iced for their UI it should receive a11y-related updates, too.
Accessibility falls under this: to my knowledge Cosmic has it, Iced does not.
This collection looks quite useful, though the component list is mostly indistinguishable from a list of components for a web framework. The webview component is the only one that seems somewhat specific to native applications. So for something like a file-open dialog you would still have to pull in something like rfd [1] and lose styling consistency
Linux is now working towards that goal as well, in the form of XDG Desktop Portal. It puts the Desktop Environment (or third party provider) in charge of providing services like the file dialog/picker/chooser for better integration/coherence. It's not been fully adopted yet, but I'm very excited about it because GTK's file chooser is just awful and I want to provide my own to those apps!
Yes. And that is (almost always¹) a good thing.
Only the designers of an app, product-owners etc. want their app to "look consistent over platforms".
Your users want the file-dialog, window-chrome, menus etc consistent too. But for them consistent means consistent with the 20+ other applications they use on a daily base. So native.
¹ Obviously some software excepted. E.g. categories like "expert software" like Blender, AutoCAD, Photoshop/CS, where dialogs must a) be optimized for their niche workflow and b) remain consistent for that user when they upgrade their OS or move between OSes. But that's an exception. Your TODO-list app or PDF reader almost certainly is not that.
Videogames.
Excel still supports MS-DOS Lotus 1-2-3 "/" commands, although it certainly doesn't look like Lotus for MS-DOS.
Basically any software people care about is an exception to your rule.
As pointed out.
I don't think what you posit is true at all, at least not in 2025. Windows itself has abandoned consistency between its native applications, with more custom and modern styling that looks nothing like what you get out of the box with Windows UI frameworks. Almost every piece of software currently running on my computer has custom chrome: the web browser, my VPN, VSCode, Discord, Steam, mouse driver, keyboard driver, laptop fan driver. The only one that doesn't is qbittorent, and it looks like a complete eyesore. It is quite literally the odd one out, so much for "consistent with 20+ other applications".
Maybe it's different in MacOS land, but from my perspective you're 20 years behind if your application is trying to blend in with the OS in any regard other than the corner in which the X button is located. That way of thinking went out of fashion decades ago, and good riddance to it because things look much better now. What I mentioned above is a pretty good representative sample of my daily use, and the more I think about other software I occasionally use, the more I am grateful that nobody else still thinks like this. LiveSplit and Asesprite come to mind as two applications that strongly benefit from having bespoke chrome and wouldn't be nearly as nice to use if they looked anything like a native Windows application. Of course, my own software uses custom chrome as well, because looking nice makes it more pleasant to use, wouldn't you know it.
It is. Windows has always had consistency issues; macOS hasn't.
I do fully admit these consistency issues were less bad in the past.
This is a problem. One that end-users may not recognize, but the cognitive load and learning curve this brings is real and costly.
It is one of the many reasons people like Mac. It's also one of the reasons people feel awkward on e.g. Ubuntu (or just linux). Because eventhough GTK is highly consistent, the apps that don't follow this consistency (Libre office, Gimp, Firefox, Thunderbird, etc) are more common than the ones that do.
This was probably true 20 years ago but is not true today.
The majority of apps your average (non-HN) user uses is actually on their phone and not using the native UI widgets.
On their desktop they’re using apps like Spotify, Slack, and Microsoft Office or Google Docs.
The average user of today is not using a lot of native apps.
Users don't want the slack they get. They'd much rather have a slack client that integrates in their OS.
The main reason I get this Slack client that's the same across OSX, Ubuntu and Windows, is because the company doesn't want to spend time building three native apps. And that's understandable and perfectly fine.
But if it cost slack more time and effort to build a single app that runs on four platforms than it would cost them to build 4 that integrate into the platform, we'd get a native client within weeks.
I don’t know anyone who doesn’t hate these apps.
I care a lot if an app on my android suddenly opens an IOS date picker.
Because I don't care about date pickers. I don't care about how it looks. All I care about is picking a date and doing that fast.
But now I have to learn a -to me- unfamiliar interface, spend cognitive load on something unrelated to what I was trying to do (e.g. schedule a date with a friend)
So many UI frameworks don't have these and require building them yourself...
Then again I love zed so I might be biased.
Coming from years of working with Qt, I'm always fascinated by the search for the "holy grail" of GUI libs. It's surprising how elusive a true "write-once-run-everywhere" solution (that's also good) still is.
My main question is about your long-term, cross-platform vision: How are you thinking about the matrix of Desktop, Web, and Embedded systems? Qt (for all its baggage) made a real run at desktop/embedded. Do you see GPUI components eventually covering all three, or is the focus purely on desktop/web for now?
Excited about the future of Rust GUI development, this is fantastic.
I'm not sure what you are talking about (there are plenty of x-platform C++ GUI toolkits with components). Maybe you mean "accelerated toolkits"?
It is also the KDE infrastructure, used in plenty of infotaiment, factory dashboards and medical devices.
I built (agentic coded) a stocks viewer app for Indian stock market data: https://github.com/brainless/Indistocks. It was a fantastic experience as to how easily I could build a GUI app.
My main product also uses egui: https://github.com/brainless/nocodo. It used to have a web app frontend and I moved to desktop app after the experiment with Indistocks. The experience has been really good, also coded with agents.
Desktop apps are fun and even on my somewhat old and slow laptop (i5 8th gen, 16 GB RAM, 2GB nvidia dedicated graphics), they are so much faster than web apps on Chrome (on Linux). I want desktop apps to make a big comeback, we could use so many old devices.
Still waiting to see more general use before attempting to port my Svelte UI for a Tauri application but it honestly looks incredible.
Big ups to the guy(s) at Longbridge.
https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...
(obviously you can also take things much higher by building more functionality into your application, but that gives you an idea of the kind of "base size" achievable).
However I find it bizarre that in the comparison table, Qt’s licensing is described as “Commercial”. Yes Qt is available under a commercial license but it’s also available under LGPL 3.
Yes that means you can even build proprietary applications linking against the LGPL license.
That makes that table misleading and borderline FUD.
webview.load_url("https://drive.google.com");