8 ms·

Rust cross-platform GPUI components

515 points by xvilka 1y ago

ape4 1y ago
A link to toolkit (GPUI) since I don't see it mentioned... https://www.gpui.rs/ https://www.gpui.rs/
nu11ptr 1y ago
This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui https://crates.io/crates/fyrox-ui. Again, not really used/known outside of fyrox. 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/crates/story https://github.com/longbridge/gpui-component/tree/main/crate... Just "cargo run --release"
- defraudbah 1y ago
  [flagged]
- airstrike 1y ago
  > 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. 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.
  - nu11ptr 1y ago
    > 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.
    - galangalalgol 1y ago
      I think you'll find two definitions of enterprise ready. People who make UIs and are comparing a UI crate to see how it stacks up, and people who write business logic in rust and only care that they were able to make a gui work without switching to some other language. I would put my org in the second situation. Someone bought the thing and didn't complain so good enough I guess. We were using egui.
      - nu11ptr 1y ago
        Ahh, gotcha. Yeah "enterprise" to me meant: "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped' app to my end users". Thanks for the reply.
        airstrike 1y ago
        FWIW that reply was from a different person :D In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"
        galangalalgol 1y ago
        The notion of shrink wrapped software dates us I think? But to that end, I have elements of so many different native looks jumbled around in my head all the way back to amiga workbench (deluxe paint was the best), that anything without really obvious flaws like off centered text or unresponsive buttons feels shrinkwrappable to me. By my standard any of these looks is enterprise ready. I remember someone at MS looking at a gui made by a team my friend was on and mocking it for looking like it was out of tron with saturated colors on a black background in high contrast instead of "modern" 3d grey buttons. It looked a lot more like the linked UI than anything MS was producing at the time. So there is the fashion aspect of it. You want to stand out, but not too much. I think that is the aspect I'm unable to judge. If everything is in the first or second place I look, I just won't care.
        andsoitis 1y ago
        > I did mean "I can write/maintain a UI rich/polished 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.
  - the__alchemist 1y ago
    Same! I am building a structural biology CAD-like tool in Rust (EGUI + WGPU), and it's a great experience.
- nicce 1y ago
  > 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 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.
  - nu11ptr 1y ago
    That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.
    - nicoburns 1y ago
      I don't think GPUI has it integrated yet, but Dioxus's Subsecond tool [0] implements binary hot-patching for Rust apps which can help alieviate this problem. 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/subsecond https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...
      - nu11ptr 1y ago
        > The other thing you can do (which is popular in the Bevy community) is to compile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds. 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)
        nicoburns 1y ago
        An actual dynlib (containing the core framework crates that typically dont change between compiles (and which in C world might be installed as precompiled system libraries)). 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.
- matu3ba 1y ago
  Since you think the UI scene is maturing: Where do I find 1. design docs and 2. debugging infra docs (Validation, Testing, Stepping, Logging, Tracing, Recording, Scheduling, Reversal Computing as typical ones) and/or how to apply them ?
  - wiz21c 1y ago
    scheduling ??? what's that ? scheduling UI events ? Reversal computing ? What's that ? You meant reversible computing ?
    - matu3ba 1y ago
      Scheduling means to generate enumerations/combinations of possible ui events. If interleaving events are possible and to what degree, then providing a notion of that and/or at least documentation would be helpful. 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 https://en.wikipedia.org/wiki/Reversible_computing and https://en.wikipedia.org/wiki/Time_reversibility https://en.wikipedia.org/wiki/Time_reversibility.
      - nathansobo 1y ago
        GPUI has a mature scheduling story, letting you “block” the main thread on spawned tasks with async/await. It also comes with a deterministic random test scheduler for driving out timing bugs.
        matu3ba 1y ago
        Thanks. Sounds like a good developer experience attempt.
- swiftcoder 1y ago
  > but unfortunately has almost no usage 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
  - rtfeldman 1y ago
    As of August 2025, Zed had 150K monthly active users. That was before it supported Windows; the number is much higher now (although not publicly reported). 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-powered-code-editor-built-from-scratch/ https://sequoiacap.com/article/partnering-with-zed-the-ai-po...
    - RMPR 1y ago
      Iirc Cosmic Desktop uses Iced
      - embedding-shape 1y ago
        Kraken seems to have a desktop application for trading made in Iced as well. I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?
    - zemo 1y ago
      users is a finicky metric. When Palia came out, a game you most likely have never heard of, I wrote a desktop installer for it with Druid, which a few million people downloaded and used to install and run Palia. Only a handful of people worked on this codebase, maybe three or four while I was there, but principally me and one other engineer. 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.)
  - michaelmior 1y ago
- Buttons840 1y ago
  Fyrox is such a blackpill for me (makes me doubt the Rust gamedev scene), because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. Instead everyone is excited about the Entity-Component-System in Bevy, but once all the rough edges of Bevy are smoothed out, people excited about the ECS are going to realize they don't actually want to make art, or create game mechanics, they were just excited about a neat system (and in fairness, ECS is neat), but they never really wanted to do the things required for a game.
  - HelloNurse 1y ago
    ECS hype and the traditional make a game/make an engine dilemma shouldn't be considered reasons to avoid the Fyrox library (or other Rust projects). Are you trying to tell something more logical? Does the "Rust gamedev scene" affect the technical merits of libraries?
    - Chris2048 1y ago
      Perhaps you should read the comment again, your questions don't follow from it.
  - pie_flavor 1y ago
    What makes Fyrox better than Bevy? I don't think the hundred people commenting under every Bevy point release on HN are thinking of the ECS. It has features and it has tools and it has games.
  - deleted 1y ago
    [deleted]
  - echelon 1y ago
    > because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. 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.
- the__alchemist 1y ago
  In terms of its state now, how does it compare to EGUI?
- rayiner 1y ago
  I downloaded the Longbride app they made with it. It looks like a real application! Fits in pretty well on Mac. Runs much more smoothly than Electron!
- zaphirplane 1y ago
  I’m so tempted to find out if Claude and friends can work with it, cause it’s new, rust and and unique
  - embedding-shape 1y ago
    With the right workflow you can work with any language and library, by managing the context carefully and "showing-not-telling". I've worked with Claude Code and Codex on lots with Rust and Clojure, seems to not have any more issues than when I use Python.
unwind 1y ago
That showcase application (other than Zed) looks awesome, but the very fancy-looking home page [1] fails to have a one-liner explanation of, uh, what the application does. Please consider fixing. [1]: https://longbridge.com/desktop/ https://longbridge.com/desktop/
- nicce 1y ago
  I guess they expect that most people come there from the top level domain. (https://longbridge.com https://longbridge.com)
- ribelo 1y ago
  "Multi-platform Support, Professional Market Monitoring" imho is a good explanation
kennydude 1y ago
Looks great for those using Rust - however I do wonder how well this works, if at all, under screen readers and other accessible tech?
- Oxodao 1y ago
  my #1 question each time I see a new UI framework
  - jacquesm 1y ago
    "Let's get the volume first, then worry about accessibility" 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.
    - wiz21c 1y ago
      at least I think egui has worked on that aspect...
    - anthony-eid 1y ago
      Accessibility is apart of gpui roadmap.
      - pseudalopex 1y ago
        > Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.
- jeroenhd 1y ago
  Haven't tried running the code myself, but their API docs mention accessibility at least: https://longbridge.github.io/gpui-component/docs/components/list#accessibility https://longbridge.github.io/gpui-component/docs/components/... Assuming the docs are correct, the UI controls seem ARIA compliant as long as you bother implementing the necessary descriptions and labels.
- 1y ago
agluszak 1y ago
I find it sad that a lot of foundational open-source software is created/maintained by trading/crypto/money laundering companies. But OTOH it's great that they at least contribute _something_ to the society!
- baq 1y ago
  Bitcoin ethos (as in, the original 'banks are broken, let's fix this') is kinda similar to the hacker ethos ('this thing/program is broken, let's fix this'), so maybe this shouldn't be too surprising? Short term pain for long term gain etc. (disclaimer: I think bitcoin is dumb, but the market disagrees)
  - nicce 1y ago
    > (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.
- philipallstar 1y ago
  I doubt that a lot of it is.
- bezbac 1y ago
  gpui itself is maintained by the folks at https://zed.dev https://zed.dev. 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? 1: https://longbridge.com/desktop/ https://longbridge.com/desktop/
  - ecshafer 1y ago
    zed looks nice, but I am going to wait until the American port to use it.
SilverSlash 1y ago
I was expecting something ugly but these actually look beautiful!
UndyingHorse 1y ago
Why is the average binary size 10MB? Does it embed ICU data?
- berkes 1y ago
  > By default, Rust optimizes for execution speed, compilation speed, and ease of debugging rather than binary size, since for the vast majority of applications this is ideal. But for situations where a developer wants to optimize for binary size instead, Rust provides mechanisms to accomplish this. https://github.com/johnthagen/min-sized-rust?tab=readme-ov-file https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...
- nicoburns 1y ago
  I can't speak for GPUI specifically, but in general for Rust UI toolkits I'm seeing about 10-15mb for an O3 build with LTO enabled and when including things like ICU data, a WGPU-based renderer, SVG rendering support, and a "full fat" async HTTP client. More minimal builds with features disabled and/or Os/Oz can bring that down to more like 5mb. (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).
ramon156 1y ago
Although its still very vertically scoped for zed, I'm way more hyped about this UI than iced, dioxus ui, gtk-rs, etc. because of how complete it already is in an early stage. Then again I love zed so I might be biased.
wongarsu 1y ago
Rust certainly needs more GUI component collections. There are lots of GUI toolkits, but a comparatively small number of prebuilt components you can use with any of them. 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 1: https://docs.rs/rfd/latest/rfd/ https://docs.rs/rfd/latest/rfd/
- patwoz 1y ago
  You should always use the native file picker and not shipping your own. That’s a good thing.
- nu11ptr 1y ago
  Even though most UI libraries now draw their own widgets some native integration is almost always used/desired. Those integrations are typically: keyboard short cuts, native system menu (macOS), native file dialogs, and (sometimes) native context menus. I'm sure there are others I'm forgetting, but these minimal integrations are a good thing as they give the user some sense of familiarity.
  - filleduchaos 1y ago
    Not just a sense of familiarity; you will simply never build the full spectrum of a file explorer's functionality in a custom file dialog, that would be a complete waste of engineering time. And many more users than you'd expect benefit from the fact that native file dialogs are actually full-fledged explorers. For example, I fairly often find myself quick-previewing a file to be sure it's the correct one when I select it.
    - tredre3 1y ago
      Thankfully on Macos x and Windows, the file picker isn't provided by the UI toolkit (though they usually provide abstract methods of calling it, for convenience). 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!
fidotron 1y ago
Is this native as in "not web" or native as in actually using native text entry and scrolling widgets? There is quite a huge difference as the Java world discovered.
- nu11ptr 1y ago
  Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).
  - mdhb 1y ago
    Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.
    - nicoburns 1y ago
      Rust's definitely well-suited to writing the low-level infrastructure pieces (the implementations of the renderer, layout, text, etc). You really want something with fast and predicatable performance there. Whether it pans out for writing actual applications we'll have to see, but a lot of big popular applications are written in C++ which is surely less suitable.
    - keyle 1y ago
      I write both swiftUI and flutter daily. I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform. But in terms of language adaptability for UI, Swift is king.
      - mdhb 1y ago
        I would say the opposite and it sounds like a personal preference at which point I think lack of cross platform compatibility ceases to anything else other than a major major problem.
brainless 1y ago
This looks very good from the screenshots. I will try this as quickly as I can. I have been building with egui and have tried Iced, Slint and Makepad. I built (agentic coded) a stocks viewer app for Indian stock market data: https://github.com/brainless/Indistocks 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 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.
rana762 1y ago
[dead]
h4x0rr 1y ago
Hola, finally a good rust ui framework that's not dependent on web
- Ygg2 1y ago
  You mean outside iced, slint, egui, etc. ?
h4ch1 1y ago
GPUI and GPUi components are the two things I'm watching very closely while evaluating truly native GUI development. 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.
the_duke 1y ago
Virtualized lists and tables are amazing! So many UI frameworks don't have these and require building them yourself...
miki123211 1y ago
Does this implement accessibility at all? 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.
- pacificat0r 1y ago
  Yes
- andrewl-hn 1y ago
  Not really. 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.
  - Klonoar 1y ago
    System76 runs their own fork of Iced and commits things back to Iced, but in practice this hasn’t been as much as people seem to think. Accessibility falls under this: to my knowledge Cosmic has it, Iced does not.
- tracker1 1y ago
  You might want to consider Dioxus if you want better accessibility in a Rust app... though afaik, there's no component library as complete as this one available.
patrick4urcloud 1y ago
very nice ! what about tauri versus this compoments ?
- ayoubmdi 1y ago
  Tauri uses a WebView to render the UI, GPUI uses (DirectX, Metal, Vulkan) directly to render the UI... Blazingly Fast hehe.
georgeburdell 1y ago
2 hours after it's posted on HN, the repo has its first "readme.md typo fix" commit.
WhyNotHugo 1y ago
The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.
- nu11ptr 1y ago
  I think this is pretty common on Linux. You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.
  - moralestapia 1y ago
    Are GTK/Qt memory safe now?
    - discreteevent 1y ago
      No. What is the likelihood of an attack on a desktop program via memory unsafety?
      - lesuorac 1y ago
        Really high? What do you run your browser as?
        discreteevent 1y ago
        Browser runs complex untrusted code from the internet. Most desktop programs don't do anything like that. The servo programmers were riding a motorbike. Using Rust for a desktop program would be more like wearing a crash helmet in a car.
      - moralestapia 1y ago
        >What is the likelihood of an attack on a desktop program via memory unsafety? Low. What's the likelihood of someone entering your house if it's unlocked? Also low, and yet you lock it.
Keyframe 1y ago
I'm interested in how's the battery life while running a thing ilke this. Another thing I'm interested in does it support rendering to texture.. usage being used as a texture on an object (monitor let's say) in a game or rendered as a texture with opacity on a quad/triangle over a screen as a UI layer or a HUD
- daakus 1y ago
  A quick check with release build on macOS shows the component demo has a non-zero energy impact in the background (per activity monitor), but the input example has zero energy impact while in the background. This is already better than many new from-scratch UI libraries. The foreground impact is harder to measure.
serinaatna19 1y ago
[flagged]
artursapek 1y ago
It seems like trading applications tend to be what demands the performance to push R&D like this for Rust GUI. My team at Kraken worked on https://iced.rs/ https://iced.rs/ which powers https://www.kraken.com/desktop https://www.kraken.com/desktop, a very similar application. You can definitely feel the difference in a Rust GUI vs. a web view. It can maintain high frame rates doing so much on the screen at once.
- nu11ptr 1y ago
  Are any pieces of this open source by chance? (other than iced itself)
  - artursapek 1y ago
    Unfortunately not
deleted 1y ago
[deleted]
ruguo 1y ago
It does look pretty solid, but whenever I’m building a desktop app with Rust, Tauri is always the first thing that comes to mind.
samiv 1y ago
Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? 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.
- paulddraper 1y ago
  WYSIWG and code are almost always if not always not done well together.
- pjmlp 1y ago
  They do, but you have to look into the right ones, from ex-Qt employees, https://slint.dev/ https://slint.dev/ 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).
  - Arch-TK 1y ago
    The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.
    - pjmlp 1y ago
      Easy, similar to Qt. 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.
sagacity 1y ago
It's interesting to see more people building on top of GPUI. I recently also saw https://github.com/Augani/adabraka-ui https://github.com/Augani/adabraka-ui which looks fairly similar.
- nu11ptr 1y ago
  This looks great too! Hopefully one or more of these component libraries catch on and stay well maintained.
ratatoskrt 1y ago
No mobile support. I get that a desktop UI framework doesn't want to target smartphones, but I think iPads (and bigger Android tablets) can cope well with more traditional desktop paradigms.
klaussilveira 1y ago
Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license. Excited about the future of Rust GUI development, this is fantastic.
- fschuett 1y ago
  Azul.rs is making lots of progress now and it'll have decent C / C++ / Python bindings (so it won't be Rust-only). But I guess for now GPUI is more mature.
- lelanthran 1y ago
  > Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license. 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"?
- pjmlp 1y ago
  Qt is modern enough, still there are hardly any Rust libraries as feature rich in capabilities and designer related tooling. It is also the KDE infrastructure, used in plenty of infotaiment, factory dashboards and medical devices.
gnarlouse 1y ago
So how stupid am I for asking how long it is before this is available in the browser and all the DOM behavior is WASM?
cultofmetatron 1y ago
it happens to be my birthday today and this is one hell of a birthday present right now. been itching to dive into making a desktop app in rust and this looks amazing!
phkahler 1y ago
Does it support app development in other languages?
criticalfault 1y ago
Now that we can do a nice toolbar and components, somebody please make a document canvas control so we can make a decent office suite.
- andai 1y ago
  webview.load_url("https://drive.google.com");
aryonoco 1y ago
Really interesting, and look forward to playing with it 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.
Animats 1y ago
Unfortunately, it's a framework. That is, it demands to own the event loop. It has a type "Application" (This is Rust, don't get to say "it has a class Application, which you subclass", but that's how it works.) That's fine for a cold start where you do everything their way, but tough if there's already an event loop. egui, in contrast, is just a library crate which needs to be called on each frame.
shmerl 1y ago
So how would it work on Linux let's say, it would need its own theming to match system look and feel of existing DE?
Trojanking 1y ago
good job !!!!
stephenlf 1y ago
Ah yes, a GUI component landing page with no pictures. Makes it tricky to imagine what the GUI looks like
aurintex 1y ago
This is really interesting. As a new Zed user, I've read about GPUI, but have no insights. 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?

515 points by xvilka 1y ago

ape4 1y ago

A link to toolkit (GPUI) since I don't see it mentioned... https://www.gpui.rs/ https://www.gpui.rs/

This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui https://crates.io/crates/fyrox-ui. Again, not really used/known outside of fyrox. 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/crates/story https://github.com/longbridge/gpui-component/tree/main/crate... Just "cargo run --release"

defraudbah 1y ago
[flagged]
airstrike 1y ago
> 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. 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.
- nu11ptr 1y ago
  > 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.
  - galangalalgol 1y ago
    I think you'll find two definitions of enterprise ready. People who make UIs and are comparing a UI crate to see how it stacks up, and people who write business logic in rust and only care that they were able to make a gui work without switching to some other language. I would put my org in the second situation. Someone bought the thing and didn't complain so good enough I guess. We were using egui.
    - nu11ptr 1y ago
      Ahh, gotcha. Yeah "enterprise" to me meant: "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped' app to my end users". Thanks for the reply.
      - airstrike 1y ago
        FWIW that reply was from a different person :D In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"
        galangalalgol 1y ago
        The notion of shrink wrapped software dates us I think? But to that end, I have elements of so many different native looks jumbled around in my head all the way back to amiga workbench (deluxe paint was the best), that anything without really obvious flaws like off centered text or unresponsive buttons feels shrinkwrappable to me. By my standard any of these looks is enterprise ready. I remember someone at MS looking at a gui made by a team my friend was on and mocking it for looking like it was out of tron with saturated colors on a black background in high contrast instead of "modern" 3d grey buttons. It looked a lot more like the linked UI than anything MS was producing at the time. So there is the fashion aspect of it. You want to stand out, but not too much. I think that is the aspect I'm unable to judge. If everything is in the first or second place I look, I just won't care.
        andsoitis 1y ago
        > I did mean "I can write/maintain a UI rich/polished 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.
- the__alchemist 1y ago
  Same! I am building a structural biology CAD-like tool in Rust (EGUI + WGPU), and it's a great experience.
nicce 1y ago
> 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 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.
- nu11ptr 1y ago
  That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.
  - nicoburns 1y ago
    I don't think GPUI has it integrated yet, but Dioxus's Subsecond tool [0] implements binary hot-patching for Rust apps which can help alieviate this problem. 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/subsecond https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...
    - nu11ptr 1y ago
      > The other thing you can do (which is popular in the Bevy community) is to compile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds. 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)
      - nicoburns 1y ago
        An actual dynlib (containing the core framework crates that typically dont change between compiles (and which in C world might be installed as precompiled system libraries)). 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.
matu3ba 1y ago
Since you think the UI scene is maturing: Where do I find 1. design docs and 2. debugging infra docs (Validation, Testing, Stepping, Logging, Tracing, Recording, Scheduling, Reversal Computing as typical ones) and/or how to apply them ?
- wiz21c 1y ago
  scheduling ??? what's that ? scheduling UI events ? Reversal computing ? What's that ? You meant reversible computing ?
  - matu3ba 1y ago
    Scheduling means to generate enumerations/combinations of possible ui events. If interleaving events are possible and to what degree, then providing a notion of that and/or at least documentation would be helpful. 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 https://en.wikipedia.org/wiki/Reversible_computing and https://en.wikipedia.org/wiki/Time_reversibility https://en.wikipedia.org/wiki/Time_reversibility.
    - nathansobo 1y ago
      GPUI has a mature scheduling story, letting you “block” the main thread on spawned tasks with async/await. It also comes with a deterministic random test scheduler for driving out timing bugs.
      - matu3ba 1y ago
        Thanks. Sounds like a good developer experience attempt.
swiftcoder 1y ago
> but unfortunately has almost no usage 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
- rtfeldman 1y ago
  As of August 2025, Zed had 150K monthly active users. That was before it supported Windows; the number is much higher now (although not publicly reported). 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-powered-code-editor-built-from-scratch/ https://sequoiacap.com/article/partnering-with-zed-the-ai-po...
  - RMPR 1y ago
    Iirc Cosmic Desktop uses Iced
    - embedding-shape 1y ago
      Kraken seems to have a desktop application for trading made in Iced as well. I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?
  - zemo 1y ago
    users is a finicky metric. When Palia came out, a game you most likely have never heard of, I wrote a desktop installer for it with Druid, which a few million people downloaded and used to install and run Palia. Only a handful of people worked on this codebase, maybe three or four while I was there, but principally me and one other engineer. 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.)
- michaelmior 1y ago
Buttons840 1y ago
Fyrox is such a blackpill for me (makes me doubt the Rust gamedev scene), because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. Instead everyone is excited about the Entity-Component-System in Bevy, but once all the rough edges of Bevy are smoothed out, people excited about the ECS are going to realize they don't actually want to make art, or create game mechanics, they were just excited about a neat system (and in fairness, ECS is neat), but they never really wanted to do the things required for a game.
- HelloNurse 1y ago
  ECS hype and the traditional make a game/make an engine dilemma shouldn't be considered reasons to avoid the Fyrox library (or other Rust projects). Are you trying to tell something more logical? Does the "Rust gamedev scene" affect the technical merits of libraries?
  - Chris2048 1y ago
    Perhaps you should read the comment again, your questions don't follow from it.
- pie_flavor 1y ago
  What makes Fyrox better than Bevy? I don't think the hundred people commenting under every Bevy point release on HN are thinking of the ECS. It has features and it has tools and it has games.
- deleted 1y ago
  [deleted]
- echelon 1y ago
  > because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. 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.
the__alchemist 1y ago
In terms of its state now, how does it compare to EGUI?
rayiner 1y ago
I downloaded the Longbride app they made with it. It looks like a real application! Fits in pretty well on Mac. Runs much more smoothly than Electron!
zaphirplane 1y ago
I’m so tempted to find out if Claude and friends can work with it, cause it’s new, rust and and unique
- embedding-shape 1y ago
  With the right workflow you can work with any language and library, by managing the context carefully and "showing-not-telling". I've worked with Claude Code and Codex on lots with Rust and Clojure, seems to not have any more issues than when I use Python.

unwind 1y ago

That showcase application (other than Zed) looks awesome, but the very fancy-looking home page [1] fails to have a one-liner explanation of, uh, what the application does. Please consider fixing. [1]: https://longbridge.com/desktop/ https://longbridge.com/desktop/

nicce 1y ago
I guess they expect that most people come there from the top level domain. (https://longbridge.com https://longbridge.com)
ribelo 1y ago
"Multi-platform Support, Professional Market Monitoring" imho is a good explanation

kennydude 1y ago

Looks great for those using Rust - however I do wonder how well this works, if at all, under screen readers and other accessible tech?

Oxodao 1y ago
my #1 question each time I see a new UI framework
- jacquesm 1y ago
  "Let's get the volume first, then worry about accessibility" 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.
  - wiz21c 1y ago
    at least I think egui has worked on that aspect...
  - anthony-eid 1y ago
    Accessibility is apart of gpui roadmap.
    - pseudalopex 1y ago
      > Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.
jeroenhd 1y ago
Haven't tried running the code myself, but their API docs mention accessibility at least: https://longbridge.github.io/gpui-component/docs/components/list#accessibility https://longbridge.github.io/gpui-component/docs/components/... Assuming the docs are correct, the UI controls seem ARIA compliant as long as you bother implementing the necessary descriptions and labels.
1y ago

agluszak 1y ago

I find it sad that a lot of foundational open-source software is created/maintained by trading/crypto/money laundering companies. But OTOH it's great that they at least contribute _something_ to the society!

baq 1y ago
Bitcoin ethos (as in, the original 'banks are broken, let's fix this') is kinda similar to the hacker ethos ('this thing/program is broken, let's fix this'), so maybe this shouldn't be too surprising? Short term pain for long term gain etc. (disclaimer: I think bitcoin is dumb, but the market disagrees)
- nicce 1y ago
  > (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.
philipallstar 1y ago
I doubt that a lot of it is.
bezbac 1y ago
gpui itself is maintained by the folks at https://zed.dev https://zed.dev. 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? 1: https://longbridge.com/desktop/ https://longbridge.com/desktop/
- ecshafer 1y ago
  zed looks nice, but I am going to wait until the American port to use it.

SilverSlash 1y ago

I was expecting something ugly but these actually look beautiful!

UndyingHorse 1y ago

Why is the average binary size 10MB? Does it embed ICU data?

berkes 1y ago
> By default, Rust optimizes for execution speed, compilation speed, and ease of debugging rather than binary size, since for the vast majority of applications this is ideal. But for situations where a developer wants to optimize for binary size instead, Rust provides mechanisms to accomplish this. https://github.com/johnthagen/min-sized-rust?tab=readme-ov-file https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...
nicoburns 1y ago
I can't speak for GPUI specifically, but in general for Rust UI toolkits I'm seeing about 10-15mb for an O3 build with LTO enabled and when including things like ICU data, a WGPU-based renderer, SVG rendering support, and a "full fat" async HTTP client. More minimal builds with features disabled and/or Os/Oz can bring that down to more like 5mb. (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).

ramon156 1y ago

Although its still very vertically scoped for zed, I'm way more hyped about this UI than iced, dioxus ui, gtk-rs, etc. because of how complete it already is in an early stage. Then again I love zed so I might be biased.

wongarsu 1y ago

Rust certainly needs more GUI component collections. There are lots of GUI toolkits, but a comparatively small number of prebuilt components you can use with any of them. 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 1: https://docs.rs/rfd/latest/rfd/ https://docs.rs/rfd/latest/rfd/

patwoz 1y ago
You should always use the native file picker and not shipping your own. That’s a good thing.
nu11ptr 1y ago
Even though most UI libraries now draw their own widgets some native integration is almost always used/desired. Those integrations are typically: keyboard short cuts, native system menu (macOS), native file dialogs, and (sometimes) native context menus. I'm sure there are others I'm forgetting, but these minimal integrations are a good thing as they give the user some sense of familiarity.
- filleduchaos 1y ago
  Not just a sense of familiarity; you will simply never build the full spectrum of a file explorer's functionality in a custom file dialog, that would be a complete waste of engineering time. And many more users than you'd expect benefit from the fact that native file dialogs are actually full-fledged explorers. For example, I fairly often find myself quick-previewing a file to be sure it's the correct one when I select it.
  - tredre3 1y ago
    Thankfully on Macos x and Windows, the file picker isn't provided by the UI toolkit (though they usually provide abstract methods of calling it, for convenience). 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!

fidotron 1y ago

Is this native as in "not web" or native as in actually using native text entry and scrolling widgets? There is quite a huge difference as the Java world discovered.

nu11ptr 1y ago
Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).
- mdhb 1y ago
  Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.
  - nicoburns 1y ago
    Rust's definitely well-suited to writing the low-level infrastructure pieces (the implementations of the renderer, layout, text, etc). You really want something with fast and predicatable performance there. Whether it pans out for writing actual applications we'll have to see, but a lot of big popular applications are written in C++ which is surely less suitable.
  - keyle 1y ago
    I write both swiftUI and flutter daily. I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform. But in terms of language adaptability for UI, Swift is king.
    - mdhb 1y ago
      I would say the opposite and it sounds like a personal preference at which point I think lack of cross platform compatibility ceases to anything else other than a major major problem.

brainless 1y ago

This looks very good from the screenshots. I will try this as quickly as I can. I have been building with egui and have tried Iced, Slint and Makepad. I built (agentic coded) a stocks viewer app for Indian stock market data: https://github.com/brainless/Indistocks 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 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.

rana762 1y ago

[dead]

h4x0rr 1y ago

Hola, finally a good rust ui framework that's not dependent on web

Ygg2 1y ago
You mean outside iced, slint, egui, etc. ?

h4ch1 1y ago

GPUI and GPUi components are the two things I'm watching very closely while evaluating truly native GUI development. 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.

the_duke 1y ago

Virtualized lists and tables are amazing! So many UI frameworks don't have these and require building them yourself...

miki123211 1y ago

Does this implement accessibility at all? 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.

pacificat0r 1y ago
Yes
andrewl-hn 1y ago
Not really. 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.
- Klonoar 1y ago
  System76 runs their own fork of Iced and commits things back to Iced, but in practice this hasn’t been as much as people seem to think. Accessibility falls under this: to my knowledge Cosmic has it, Iced does not.
tracker1 1y ago
You might want to consider Dioxus if you want better accessibility in a Rust app... though afaik, there's no component library as complete as this one available.

patrick4urcloud 1y ago

very nice ! what about tauri versus this compoments ?

ayoubmdi 1y ago
Tauri uses a WebView to render the UI, GPUI uses (DirectX, Metal, Vulkan) directly to render the UI... Blazingly Fast hehe.

georgeburdell 1y ago

2 hours after it's posted on HN, the repo has its first "readme.md typo fix" commit.

WhyNotHugo 1y ago

The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.

nu11ptr 1y ago
I think this is pretty common on Linux. You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.
- moralestapia 1y ago
  Are GTK/Qt memory safe now?
  - discreteevent 1y ago
    No. What is the likelihood of an attack on a desktop program via memory unsafety?
    - lesuorac 1y ago
      Really high? What do you run your browser as?
      - discreteevent 1y ago
        Browser runs complex untrusted code from the internet. Most desktop programs don't do anything like that. The servo programmers were riding a motorbike. Using Rust for a desktop program would be more like wearing a crash helmet in a car.
    - moralestapia 1y ago
      >What is the likelihood of an attack on a desktop program via memory unsafety? Low. What's the likelihood of someone entering your house if it's unlocked? Also low, and yet you lock it.

Keyframe 1y ago

I'm interested in how's the battery life while running a thing ilke this. Another thing I'm interested in does it support rendering to texture.. usage being used as a texture on an object (monitor let's say) in a game or rendered as a texture with opacity on a quad/triangle over a screen as a UI layer or a HUD

daakus 1y ago
A quick check with release build on macOS shows the component demo has a non-zero energy impact in the background (per activity monitor), but the input example has zero energy impact while in the background. This is already better than many new from-scratch UI libraries. The foreground impact is harder to measure.

serinaatna19 1y ago

[flagged]

artursapek 1y ago

It seems like trading applications tend to be what demands the performance to push R&D like this for Rust GUI. My team at Kraken worked on https://iced.rs/ https://iced.rs/ which powers https://www.kraken.com/desktop https://www.kraken.com/desktop, a very similar application. You can definitely feel the difference in a Rust GUI vs. a web view. It can maintain high frame rates doing so much on the screen at once.

nu11ptr 1y ago
Are any pieces of this open source by chance? (other than iced itself)
- artursapek 1y ago
  Unfortunately not

deleted 1y ago

[deleted]

ruguo 1y ago

It does look pretty solid, but whenever I’m building a desktop app with Rust, Tauri is always the first thing that comes to mind.

samiv 1y ago

Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? 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.

paulddraper 1y ago
WYSIWG and code are almost always if not always not done well together.
pjmlp 1y ago
They do, but you have to look into the right ones, from ex-Qt employees, https://slint.dev/ https://slint.dev/ 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).
- Arch-TK 1y ago
  The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.
  - pjmlp 1y ago
    Easy, similar to Qt. 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.

sagacity 1y ago

It's interesting to see more people building on top of GPUI. I recently also saw https://github.com/Augani/adabraka-ui https://github.com/Augani/adabraka-ui which looks fairly similar.

nu11ptr 1y ago
This looks great too! Hopefully one or more of these component libraries catch on and stay well maintained.

ratatoskrt 1y ago

No mobile support. I get that a desktop UI framework doesn't want to target smartphones, but I think iPads (and bigger Android tablets) can cope well with more traditional desktop paradigms.

klaussilveira 1y ago

Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license. Excited about the future of Rust GUI development, this is fantastic.

fschuett 1y ago
Azul.rs is making lots of progress now and it'll have decent C / C++ / Python bindings (so it won't be Rust-only). But I guess for now GPUI is more mature.
lelanthran 1y ago
> Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license. 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"?
pjmlp 1y ago
Qt is modern enough, still there are hardly any Rust libraries as feature rich in capabilities and designer related tooling. It is also the KDE infrastructure, used in plenty of infotaiment, factory dashboards and medical devices.

gnarlouse 1y ago

So how stupid am I for asking how long it is before this is available in the browser and all the DOM behavior is WASM?

cultofmetatron 1y ago

it happens to be my birthday today and this is one hell of a birthday present right now. been itching to dive into making a desktop app in rust and this looks amazing!

phkahler 1y ago

Does it support app development in other languages?

criticalfault 1y ago

Now that we can do a nice toolbar and components, somebody please make a document canvas control so we can make a decent office suite.

andai 1y ago
webview.load_url("https://drive.google.com");

aryonoco 1y ago

Really interesting, and look forward to playing with it 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.

Animats 1y ago

Unfortunately, it's a framework. That is, it demands to own the event loop. It has a type "Application" (This is Rust, don't get to say "it has a class Application, which you subclass", but that's how it works.) That's fine for a cold start where you do everything their way, but tough if there's already an event loop. egui, in contrast, is just a library crate which needs to be called on each frame.

shmerl 1y ago

So how would it work on Linux let's say, it would need its own theming to match system look and feel of existing DE?

Trojanking 1y ago

good job !!!!

stephenlf 1y ago

Ah yes, a GUI component landing page with no pictures. Makes it tricky to imagine what the GUI looks like

aurintex 1y ago

This is really interesting. As a new Zed user, I've read about GPUI, but have no insights. 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?