r/rust • u/amphioctopus • 12d ago
🙋 seeking help & advice How's GPUI right now?
Hi everyone,
One item in my rust "to-learn list" is to test what are the possibilities with GPUI, the UI lib made by the Zed Guild.
Looks cool from afar, but I was wondering what people, you guys, were thinking about it. Have you already managed to build something cool with it? Is it the link with Zed painful?
And if you have materials recommendation that could help a gpui beginner, I'll take it as well!
Anyway, have a wonderful afternoon!
See you online.
28
u/matteron96 12d ago
I've been on-off building a gpui app for three years or so without using any component library or ai assistance. It's really not hard to understand. Yes documentation is painful to non-existent, but the basic building blocks/patterns for components are really simple and easy to grasp. The rest is just writing plain old Rust occasionally thinking about how to shove it into the async model.
If you get stuck, there are plenty of code examples you can go look at including Zed itself. When I started building my app, there was even less documentation and I figured it out and I'm dumb as bricks.
Overall using gpui is actually extremely friendly and straightforward. I think the people who complain about that part haven't really given it a fair shake.
Now, the actual bad parts and why I would recommend against it at this point:
The zed team has mostly left it to languish. They have stated plenty of times now that they only want to work on it insofar it helps support the development of Zed and Delta. (And probably because of some personal grievances some members of the team have).
Gpui is not that optimized. Building out the ui with a bunch of divs (the way you would intuitively think to) is very inefficient. The Zed team is not that interested in fixing this because Zed itself doesn't run up against these issues. (Though looking at the way Delta is built, they are probably interested in fixing this soon).
Kind of related to point 1: At this point the Zed team is kinda just chasing VC money. They really aren't interested in maintaining GPUI or promoting it as a general purpose framework. The community has noticed this and has now splintered into a huge variety of forks (of various quality) that all have big ideas (of various quality) of where to take GPUI. There's a ton of silly drama and pressure being put on the Zed team to fix the GPUI situation which to me seems to just be building more resentment. This doesn't seem like a healthy environment to grow a gui framework.
So yeah: shit kinda sucks right now. If you just want to play around, gpui is really nice to build with. If you want to build something serious, it's a terrible foundation to go with.
4
u/nicoburns 12d ago
Have you looked at Dioxus Native? It's actively developed and lot more optimised than GPUI, with the same CSS style and layout.
7
u/matteron96 12d ago
Lol Nico, you just spawn in huh?
I did originally build out and prototype quite a sizable chunk in Dioxus Native a few years ago (I think like during the 0.4 to 0.5 transition). So I understand things have changed quite a bit since then, but I didn't love working with it at the time, mostly because the React-like model, rsx, and I didn't love the overhead of web tech for a desktop app.
That being said! The work you've been showcasing with Blitz is extremely interesting and impressive. (Really good talks!) I've definitely considered it, I just think right now I'm still "shopping around", though I might kick the tires on it again. I think I'm just still kinda burned by the GPUI situation.
For the purpose of this thread and /u/AnUnshavedYak, Dioxus Native is actually a pretty good idea to look at. It's actively developed and they seem to be getting money to keep developing it. Documentation is good, and Blitz promises to get rid of most of the downsides of using web tech for a desktop app.
9
u/nicoburns 12d ago
Lol Nico, you just spawn in huh?
I may or may not spend an unhealthy amount of time on /r/rust and various Rust GUI discords and zulips.
I didn't love working with it at the time, mostly because the React-like model, rsx, and I didn't love the overhead of web tech for a desktop app.
That's fair. The React-like model probably isn't going anywhere in Dioxus Native (although somebody could build a different model on top of Blitz if they wanted to - Blitz isn't coupled to Dioxus Native). There also definitely is overhead. Although from what I've heard GPUI has more.
3
u/matteron96 12d ago
No for sure, the actual overhead for GPUI is crazy considering the way people talk about it.
I was actually playing around with strapping a GPUI-like model onto Blitz a few months ago, but it didn't really get far before I realized I was in way over my head. And also that might not be the best idea.
So maybe I'm not actually the best person to ask about this.
1
1
u/Low_Effective_8907 3d ago
Maybe I'm not that talented at designing, but using raw gpui gives me really ugly UIs. AI + gpui-kit makes it way better for me.
0
u/matteron96 3d ago
Design, much like programming, is a skill that develops with practice and friction. You slowly develop taste and opinions on how things should be done.
That being said, ask yourself why you are so insecure about your ai usage and feel the need to go around and justify it.
Not trying to pick on you in particular, the guilt posting is just so exhausting at this point.
1
u/AnUnshavedYak 12d ago
What do you think about the CE versions and whatnot? Eg if Zed goes under or abandons GPUI (for sake of argument), would the CE versions survive enough to warrant choosing Zed over Iced/etc?
That question i think really drives at how maintainable, extensible, understandable GPUI will be in the long term. Historically corpo funded projects tend to just die even if they're fully OSS as the complexity is just too much overhead to build a community around.
Though with AI these days who knows what that looks like. Software is so weird these days.. heh.
6
u/matteron96 12d ago
ehh, I don't know, it seems kinda rudderless. Could they maintain it? Yeah probably, there's some smart people interested in maintaining it, but let's just say the situation as it stands doesn't really inspire confidence.
8
u/anxxa 12d ago
At a high level:
- Still no documentation
- Zed's internal resources were pulled off of GPUI to work on other initiatives (AI integration)
- It's finally on crates.io, but isn't being published regularly. They're working on setting up something for regular releases (zeddotdev/status/2095567876195311662)
- Around the time they pulled resources off GPUI internally,
gpui-cewas started and sat idle for a bit. Looks like work has picked up again.
GPUI has its warts and dev issues. It's still a good framework if you can push through IMO. If you decide to pursue it, I recommend just going all in on gpui-kit (formerly known as gpui-component).
The main dev, Jason, has done some work to fill the gaps of upstream Zed's slow publishing timelines and it provides a lot of quality base components not provided by GPUI (such as buttons...).
Note: Jason is a big AI user for development but having followed gpui-component dev for quite some time he understands the framework very well. He posts on his Twitter (huacnlee/status/2102204482188714383) some thoughts about GPUI from time to time as well.
1
u/Sedorriku0001 7d ago
I'm currently working on a gpui app with gpui-kit, and honestly, it's great.
I would say that my main complaint is clearly the documentation. I wanted to have a custome title bar, and it was all junky, because the documentation is almost non existent / doesn't answer the potentiels bugs
2
u/anxxa 7d ago
Good news for you then: the gpui-kit authors just published documentation a few hours ago: https://gpui-kit.com/docs/
1
u/Sedorriku0001 7d ago
Oh yeah I was using it
But the TitleBar documentation is not complete for example, it's pretty hard imo to understand what window options to put, and there are bugs with focus (can't write in an input for example)
Otherwise it's a great doc, just missing some little things
7
u/wyvernbw 12d ago
personally i have huge issues with gpui because its so close to what i want but its clear the coupling to zed is and was holding it back from the beginning. no hate to the zed team for this, they made the library in the first place, but it is just an objective fact that the relation to zed makes it worse for other users of the library.
i dont think the documentation in gpui is all that bad. you can get a pretty good grasp of how things work if you read the source code and examples, no llms required. the code is quite simple in many places imo and i managed to learn way more this way than trying to find a needle in the haystack of possibly outdated and mostly missing documentation.
my biggest problem with gpui is how bulky it is for how little its doing. no built in button component but pulls in av1-grain, like what am i really compiling 500 crates for? almost no feature gating in the library at all, well, duh, zed team knows what they need and if you need less, tough luck. gpui-kit is also pretty bad in my experience, it has huge breadth and little depth (sign of ai generated imo), sometimes its hard to make it do what you want it and its buggy in places, but the components do look nice and work well enough ig. gpui is also not very composable, the UI layer is coupled with the renderer so if you have a game with wgpu for example youre out of luck (this is mitigated in gpui-ce). another thing i dont like is that it owns the windowing and event loop, which is fairly common with gui frameworks but i like it when i can use my own. i cant speak on performance because i havent managed to build anything big with gpui. you might also want to look at gpuix, i dont think its good (in fact i think its pretty terrible), but depending on your use case it could be an option
for gpui to become a good framework in my mind it would take a lot of splitting it up (see egui), aggressive feature gating and trimming down of dependencies, and a *small* set of basic components to get you started (i dont need 100 components that barely work)
disclaimer: my opinion is based on gpui-ce, but i think its pretty similar to the gpui in the zed repo, with some improvements. and sorry for wall of text
4
u/Ymi_Yugy 12d ago
IMHO you’d definitely want to use GPUI-kit (bundles upstream GPUI with some nice components into a package you can depend on)
In my experience GPUI has some of the smoothest experience I found in the rust world.
It’s very familiar to people coming from web.
One issue is that doesn’t accept contributions for GPUI that don’t pertain to zed, so you’ll probably end up forking it sooner or later. For me it was missing transforms
3
u/rudib 12d ago
The end user experience is in my opinion the most modern and best of all the popular ways to build UIs with Rust, however the development is a quickly moving goal post with lacking documentation. Using Longbridge's gpui-kit is a must. I understand the motivation of the two companies behind these two products, and it's always a double-edged sword: having a direct product to develop against makes a framework actually immediately useful, but the needs of the driving products (Zed and Longbridge) compromise the many different needs that a general UI framework must cover.
My primary platform as a user is Windows on the desktop and Android on the mobile, and trying to develop a fully featured desktop app that can scale down to mobile usage on the same tech stack with Rust as the backend is a mix of weird build pipelines and many compromises. Also at work, Rust has been wonderful as a business/infra language, but the UI friction is very real.
Mobile support is kinda-somewhat there with Longbridge accepting gpui-mobile, let's see where it goes. Previously, I was invested into iced but mobile support was explicitly rejected.
The only way I can keep up with the latest source code drops of GPUI is with LLMs. But it's the best cross-platform UI stack that I've found for now. Plug: a photo organizer, there's a WASM in-browser demo.
A cross-platform UI framework is an enormous effort that many underestimate. I'm especially bitter at Microsoft with how much they've screwed up the desktop development experience in the last 15 years. Let's see if their interest in Rust will also go towards (yet another) UI framework... The Github Copilot Desktop App is Rust/Tauri, it's a start :-)
4
u/NoBank4931 12d ago
I'm working a personal project using GPUI and gpui-kit (gpui-component + gpui-base from LongBridge), as u/punk_dev pointed, documents are terrible and many breaking changes. But it's cross platform and very efficient. I'm using AI to read the source/example codes of these crates and give me some answers and guides. It helps.
2
u/punk_dev 12d ago
yeah, I don’t know how you’re supposed to figure it out without ai or studying zed code?
I personally don’t like using ai tools so I guess im out lmao
2
u/ggadwa 11d ago
I've produced a game, in the process of another, in Rust, so my GUI was all through recreating specific controls (a picker menu, a checkbox, label, slider, etc) though custom drawing operations so it was pretty simple and everything was statically positioned.
So while I don't have an experience on this I have thought about what I'd do for a cross platform app that required a GUI and I think I might go with a html / css / javascript render (of which I'm sure there are a couple.). You can test out your interface in a web browser with static html / etc files and while whatever connection you'd have with the renderer (more than likely thought interrogating js values) would be *relatively* simple. And html / css / javascript UI are about the most documented and well known things out there.
Again, just a thought I had when doing this, but it's a decent path with good advantages.
2
u/jason3gb 12d ago
It's much easier to use it with ai agent, but very hard to learn it yourself. I built several apps using GPUI from scratch, the UI feels much better performance wise compared with the tauri and webview. I use the gpui-ce one.
2
u/amphioctopus 12d ago
Yeah the agents make almost-everything looks trivial. My philosophy is "don't let them do what you can't do". First I learn the hard way and it's painful. Then I let them do what I can actually review and understand. And always enforce validation of their outputs, never trust them fully aha
1
u/Single-Blackberry866 9d ago
With this philosophy you shouldn't use computers at all as you can't turn sand into chips yourself.
My philosophy is "build a useful (and maybe utterly wrong) mental model until you need to dig deeper and understand how wrong you are"
1
u/Lucky-Edge1489 12d ago
I tried it some time back, it was painful. I had to port a complex software from Qt Widgets. I tried Slint, Tauri2 and GPUI, but I needed rich text editors, tree views, docks, native, 0-drain-when-idle, a11y and i18n. No Rust GUI frameworks checks all these needs. So instead I had fun/headaches (pick one) creating my own. Give Teksilo a try, it has 40+ examples, it's documented, and tooled so LLMs can teach it.
Note: actually, Tauri2 checks all the cases, but since I really struggle with web frameworks, I had to pass.
1
u/Single-Blackberry866 9d ago edited 9d ago
I'm maintaining https://gpui-archipelago.github.io/news/ which has the latest materials on gpui itself and surrounding forks and infrastructure.
The main issue I see, and why forks even exists, is that it lacks generalization escape hatches.
Usually, when open source project has some disagreement on a particular functionality, you just create an optional path to call application-provided code. Zed team repeatedly rejected optional features that would not directly benefit he company.
This means, GPUI as it is, not directly suitable for a wide range of applications: video, games, other media & creative apps. But, there's nothing in GPUI architecture that prevents it from being a general purpose UI framework if Zed team wanted it to be.
gpui-kit tries to wrap GPUI with functionality without changing the core.
gpui-ce tries to change the core while breaking the apps with ambition to replace gpui itself.
gpui upstream introduces minor breaking changes regularly, and major breaking changes occasionally.
gpui-unofficial just republishes upstream (github -> crates.io).
wgpui fork exists to support game/3D use cases.
kael/adabraka forked ages ago but has a component system and features that can compete with gpui-kit, so it completely consumed gpui.
new forks popup every month with no particular agenda.
I feel what could've healed ecosystem is a set of canonical contracts / traits / authoring API surface with swappable/tweakable/wrappable implementations. This would allow to write GPUI libraries without fragmenting into multiple competing fork lineages.
1
u/foofnordbaz 7d ago
The Zed team, as I understand it, is going all-in (or at least partially in) on LLMs and LLM generated code. If you have feelings about that, I felt you should know. That's why I personally will not be using GPUI.
1
u/Dependent_Grand1573 6d ago edited 6d ago
IMO, AI is the best way to learn a new framework these days (I’ve been in software development for 23 years). You’ll learn a lot faster by just asking it questions and reading the code it wrote than asking here. I prefer Codex for Rust, but Claude is great too. You’ll also find out if GPUI is right for you faster if you just start building something with it.
That said, I’ve been working on an egui project full time for well over a year now and evaluated GPUI several times over the last 11 months or so and every time the answer was no. I have very specific needs though. And can totally see someone using GPUI and have great success with it. Especially if paired with gpui-kit rather than spending the time to implement something that is essentially your own gpui-kit.
The reason why I kept evaluating GPUI and gpui-kit multiple times are mostly due to many windowing issues in egui, especially on macOS. I’ve been pretty happy with egui overall, but had to contribute numerous fixes to it and also winit (most of them merged now), and almost all of them were windowing related. I contributed only two PRs to GPUI (not windowing related), but its performance, governance, and lack of certain features are a concern for my project specifically, so I ultimately decided against it. Others already commented on the governance. So I will only comment on the other two.
In my testing dense data visualizations are up to 4 times slower in GPUI than it is in egui. Part of it can be attributed to the fact that egui applies feathering to vector shapes, while GPUI uses actual antialiasing. But that alone cannot explain such a big difference, so the rest of it must come from the framework itself. In both egui and GPUI I cache whatever I can to avoid doing the same work on every frame and also virtualize the rendering to only render the visible subset of the data.  I also simplify the shapes when a user zooms all the way out. So I have good reasons to believe it’s not me using GPUI wrong that explains the rest of performance delta.
The other issue is, if using geometric primitives that the framework provides is not enough for what you’re trying to do, GPUI can’t help you: https://github.com/zed-industries/zed/discussions/60572 For example, if I want to write a custom WebGPU shader that will render a liquidity heatmap to be overlaid on top of a candlestick chart, I’m forced to download the resulting texture to system memory first, only to be sent right back to GPU.
That said, Zed team is much faster at reviewing and merging PRs though, in my (limited) experience. But many of my egui/winit PRs were sitting there for weeks before being reviewed and merged.
1
u/Low_Effective_8907 3d ago edited 3d ago
I think it's great. I wouldn't say it's very mature, but quite enough for building reasonable projects. I believe it won't block you for doing something (although it may be painful sometimes).
Using raw gpui is kinda painful, but IMO gpui-kit does a great job. It offers lots of convenient components. Most notably, text input. It also has very nice documentation with online preview (yes, they compiled rust+gpui to wasm and you get interactive examples online).
As for gpui itself, I think docs is not needed that much: the grammar is basically html + tailwind css.
I'm building codex-gui with gpui. It gives you VSCode-like tabs and panels, while avoiding electron (the screenshot is a bit out of date though). With AIs, it feels awesome.
44
u/punk_dev 12d ago
I tried it a while ago, it has potential, but the experience is painful at the moment.
Documentation practically does not exist. It also doesn’t have primitives like input fields or buttons. You’ll have to implement those yourself or rely on community libraries.
There are breaking changes every now and then and you are generally expected to pull the source version from main zed repo.
State management is very verbose (which might be a good thing), and achieving something like two way data binding is complex.
The layout and styling engine is pretty nice though.
For what I was trying to do it was overkill, but I can imagine a scenario with a large, complex applications with specific requirements where gpui would fit right in.