Zed editor switching graphics lib from blade to wgpu

Using mainstream libraries instead of reinventing the wheel would have been a good decision with or without VC money.

I like Zed but it's still my secondary editor because it's missing usability features that I value in other editors. I think we all benefit if they focus their attention on the parts of Zed that differentiate it rather than writing new frameworks and libraries.

You vastly overestimate the amount of pressure a board can place on an early stage startup. The far more likely scenario to me (someone who raised VC money) is that the CEO likely looked at their run rate and decided to prioritize things more aggressively. This is hardly surprising and it has nothing to do with VCs.

What's that, doing actual work rather than labor-of-love open source stuff? Seems reasonable.

Did you not raise a bunch of money from Sequoia? Sounds like you're in a perfect place to quit your job and hack on GPUI for us.

Without such venture capital, I doubt GPUI, at least to the level of complexity it has today rather than being a toy project, would have even existed. It costs money to develop open source sustainably.

They really should focus on fixing bugs and improving basic functionality.

Eg if you edit or create a file outside of Zed, there’s a good chance it won’t show up in the file browser.

Also… multi window doesn’t exist so the multi monitor story is trash.

[dead]

I recently saw a PR where the author implemented shaders but it was closed by the maintainers as the feature wasn't needed by Zed the editor.

I would be curious to hear about where folks are finding gaps in the rust ui ecosystem though...

I've written quite a lot of rust UI code for Zed over the past few years so I'm mostly familiar with the pros and cons of gpui, but I haven't spent much time with Iced, Dioxus, Xilem, etc.

I don't think it means they're struggling financially. I think it means they're not steering the ship alone any more, and are responsible to others. That's how accepting investment money generally works.

[dead]

Text editors are for cleaning up after the agents, of course. And for crafting beautiful metaprompt files to be used by the agentic prompt-crafter intelligences that mind the grunt agents. And also for coding.

Iced seems really promising, however, it's a passion project by a single developer. They very clearly stated that their goal is to follow their passions and desires first, everyone else second, and that it will always be a single person project. Their readme even discourages contributions.

Companies using it in production are often forking it as a result, and trying to keep their fork in sync. Ultimately, if the community wants iced to become a major and stable framework, it will have to be forked and a community development model built around it.

And I'm not saying this to disparage the author in any way, their readme even seems to suggest that that's exactly what they'd prefer.

I'm partial to Dioxus with their native renderer coming up, it should work cross-platform on mobile, web, desktop like Flutter (except web is actually HTML and CSS, not canvas) rather than only desktop which is what most Rust GUI frameworks are targeting.

https://github.com/DioxusLabs/blitz

Not contesting your claim, but would you mind sharing what major hardware vendor you mean?

I love iced and wrote a decent amount of code using it, but in my mind the biggest sponsor is system76 - and as awesome as they are they aren’t a major vendor yet :)

Not sure how the UI engine itself compares, but to me it is all about the available components (as a total non-designer, although AI helps with that now). The only choice I have at the moment that would meet my needs is gpui, as gpui-component now exists.

There is also Slint : https://slint.dev They are also backed by a company, and have kept a stable 1.x release for some time.

Lucky you. It still crashes quite often for me and it drives me nuts that my Claude code history is lost every time…

But love the project and been using it for almost 2 years now though

I appreciate the info! Are you able to talk me through how to move a struct[class]?

I think this is the source of the confusion:

> To describe it, I coined the term “Single-path Immediate Mode Graphical User Interface,” borrowing the “immediate mode” term from graphics programming to illustrate the difference in API design from traditional GUI toolkits.

— https://caseymuratori.com/blog_0001

Obviously it’s ludicrous to attribute “immediate mode” to him. As you say, it’s literally decades older than that. But it seems like he used immediate mode to build a GUI library and now everybody seems to think he invented immediate mode?

It's like the common claim that data-oriented programming came out of game development. It's ahistorical, but a common belief. People can't see past their heroes (Casey Muratori, Jonathon Blow) or the past decade or two of work.

There's also good reasons that immediate mode GUIs are largely only ever used by games, they are absolutely terrible for regular UI needs. Since Rust gaming is still largely non-existent, it's hardly surprising that things like 'egui' are similarly struggling. That doesn't (or shouldn't) be any reflection on whether or not Rust GUIs as a whole are struggling.

Unless the Rust ecosystem made the easily predicted terrible choice of rallying behind immediate mode GUIs for generic UIs...

I mean, fair enough, but [at least] wikipedia agrees with that take.

> Graphical user interfaces traditionally use retained mode-style API design,[2][5] but immediate mode GUIs instead use an immediate mode-style API design, in which user code directly specifies the GUI elements to draw in the user input loop. For example, rather than having a CreateButton() function that a user would call once to instantiate a button, an immediate-mode GUI API may have a DoButton() function which should be called whenever the button should be on screen.[6][5] The technique was developed by Casey Muratori in 2002.[6][5] Prominent implementations include Omar Cornut's Dear ImGui[7] in C++, Nic Barker's Clay[8][9] in C and Micha Mettke's Nuklear[10] in C.

https://en.wikipedia.org/wiki/Immediate_mode_(computer_graph...

[Edit: I'll add an update to the post to note that Casey Muratori simply “coined the term” but that it predates his video.]

> Maybe he might have made it known to people

Yes, he coined the term rather than invent the technique

Yes, one argument that I didn't make in the post but that does favor immediate mode is that you can somewhat straightforwardly convert from an immediate mode GUI to retained mode by just introducing your own abstractions. In some sense this makes you more disciplined about the FPS which could be a net win over all.

[Note that Tritium at least is translated into a number of a different languages. That part isn't that hard.]

If your main gripe about the Rust GUI ecosystem is that it's not mature then rewinding 20 years and using Qt/WPF/etc sounds like an excellent alternative. Old and mature versus modern and immature.

I am not convinced a thin FFI wrapper needs frequent updates, pending updates to the underlying API. What updates do you think it should have?

The canonical Vulkan wrapper is wgpu.

I 100% agree on pretty much everything. The "webapp masquerading as a native app" is a huge problem, and IMO, at least partially because of a failure of native-language tooling (everything from UI frameworks to build tools --- as the latter greatly affect ease of use of libraries, which, in turn, affects popularity with new developers).

To be honest, I've been (slowly) working towards my own native GUI library, in C. It's a big undertaking, but one saving grace is that --- at least on my part --- I don't need the full featureset of Qt or similar.

My plan for the portability issue is to flip the script --- make it a native library that can compile to the web (using actual DOM/HTML elements there, not canvas/WebGL/WGPU). And on Android/iOS/etc, I can already do native anyway.

Though I should add that a native look is not a goal in my case (quite a few libraries already go for that, go use those! --- and some, like Windows, don't really have a native look), which also means that I don't have to use native widgets on e.g. Android. The main reason for using DOM on the web is to be able to provide for a more "web-like" experience, to get e.g. text selection working properly, as well as IME, easier debuggability, and accessibility (an explicit goal, though not a short-term one --- in part due to a lack of testers). Though it wouldn't be too much of a stretch to allow either canvas or DOM on the web at that point --- by treating the web the same as a native platform in terms of displaying the widgets.

It's more about native performance, low memory use, and easy integration without a scripting engine inbetween --- with a decent API.

I am a bit on the fence between an immediate-mode vs retained-mode API. I'll probably do a semi-hybrid, where it's immediate-y but with a way to explicitly provide "keys" (kind of like Flutter, I think?).

https://news.ycombinator.com/item?id=47003569

The Zed team said it themselves. There is a direct quote in the parent thread.

You're right, and I think that's because the core functionality of a UI lib is not too difficult. I've tinkered in that space myself, and it's a fun side project.

Then you start to think about full unicode support, right-to-left rendering, and so on. Then you start to think about properly implementing accessibility features. The necessary work increases by a magnitude. And it's not fun work. So you stall out with a bare-bones implementation.

https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...

I started writing a program that needed to have a table with 1 million rows. This means it needs to be virtualised. Pretty common in GUI libraries. The only Rust GUI library I found that could do this easily was gpui-component (https://github.com/longbridge/gpui-component). It also renders text crisply (rules out egui), looks nice with the default style (rules out GTK, FLTK, etc.), isn't web-based (rules out Dioxus), was pretty easy to use and the developers were very responsive.

Definitely the best option today (I would say it's probably the first option that I haven't hated in some way). The only other reasonable choices I would say are:

* egui - doesn't render very nicely and some of the APIs are amateurish, but it's quick and it works. Good option for simple tools.

* Iced - looks nice and seemed to work fairly well. No virtualised lists though.

* Slint (though in some ways it is weird and it requires quite a lot of boilerplate setup).

All the others will cause you pain in some way. I think the "ones to watch" are:

* Makepad - from the demos I've seen this looks really cool, especially for arty GUI projects like synthesizers and car UIs. However it has basically no documentation so don't bother yet.

* Xilem - this is an attempt to make an 100% perfect Rust GUI library, which is cool and all but I imagine it also will never be finished.

The problem is that Zed has understandably and transparently abandoned supporting GPUI as an open source endeavour except to the extent contributions align with its business mission.

I tried gpui recently and I found it to be very, very immature. Turns out even things like input components aren't in gpui, so if you want to display a dialog box with some text fields, you have to write it from scratch, including cursor, selection, clipboard etc. — Zed has all of that, but it's in their own internal crates.

Do you know how well gpui-component supports typical use cases like that? Edit boxes, buttons, scroll views, tables, checkbox/radio buttons, context menus, consistent native selection and clipboard support, etc. are table stakes for desktop apps.

They're just straining already-strained resources on the "contributions" side and pushing interest in other directions (e.g. Electron).

What’s the point of writing open source if it’s just going to be vacuumed up by the AI companies and regurgitated for $20 a month.

Same, except for me Zed is one of the only editors that has emacs keybindings!

> they felt their native renderer on those platforms was better and less memory intensive

This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way.

Yes, but they can add a flag to switch renderers on startup like they had for blade.

Zed already has a client/server editor architecture: https://zed.dev/docs/remote-development

I didn't realize that, super exciting!

I believe they're referring to running Zed entirely in a browser. This opens up possibilities like using zed for something like codepen, or embedding it into a git web frontend like gitea. Many projects like this basically embed vscode, a rare benefit of being an electron app which Zed is not.

Sure it takes very little hardware power to do this, but Zed isn't actually setup for this yet. This is in theory and after a few more API's are adapted.

I think you might be misunderstanding the parent comment. It sounds to me like they're arguing in favor of wrapping C GUI library when writing a GUI app in Rust, not avoiding Rust entirely. As far as I can tell, they're arguing for writing new stuff in Rust that happens to be re-using some components that aren't in Rust. I'd argue that's entirely in the spirit of Rust; kind of the whole point is that you can put a hard boundary on where the unsafety lies and make everything safe outside of that boundary. When I use a Vec or a HashMap, there's unsafe code under the hood, but it doesn't stop me from writing my own code without needing to dip into unsafe at all, and there's no fundamental reason why the same couldn't be done by wrapping Qt or Gtk on Linux or Cocoa or MacOS.

Ah, I meant to reply to https://news.ycombinator.com/item?id=47003058. Never questioned the use of Rust, only the need for the entire windowing stack to be in Rust (that blog post shows a case where it bit them)

One could argue that Rust isn't well suited for GUI development at all, where class-based OOP really shines.

Then there is the issue that the Rust community likes to rewrite classic C programs because of "memory safety" and "modern tooling," but really just focuses on the easy 80% of the work. It feels like these rewrites are more done to gain popularity on GitHub than anything, as they most often remain incomplete and never replace the original implementation.

Finally there is the GPL to MIT licensing issue, on which much has been said already.

Rust build times are not an enjoyable part of its DX

They are talking to their users, it's not those that use Zed it's the VC firm that funds them. They seem to be implementing everything those users want.

I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually.

bitmap fonts are the only fonts where I can get crisp, sharp, and not blurry text. I don't have an expensive "Retina" style display.

Tried it when it when that update released and just now, still blurry as ever.

kvark was also involved in the initial implementation of zed's blade backend... which probably contributed.

Do you think Vulkan will become "nice" to use, could it ever be as ergonomic as Metal is supposed to be?

The modern Vulkan binding model is relatively fine. Your entire program has a single descriptor set containing an array of images that you reference by index. Buffers are never bound and instead referenced by device address.

Khronos is trying to entice scientific folks with ANARI, because there was zero interest to move from OpenGL as you mention.

https://www.khronos.org/anari/

Agreed, multibuffers are such a huge QOL feature. I love being able to work across a dozen or more buffers at once with no impact on performance. You can work in so many places at once, navigate from the buffer to its file and back, widen the buffer up or down, etc. It feels like a super power.

Is Zed really fully native?

Last time I tried it (few months back) it felt really slow. Truns out it was spawning nodejs servers and using tons of memory.

Honestly, vscode was much faster for me (and looked much better).

My tone probably came off as antagonistic and that was not my intention. I was interested in if anyone was using the high fidelity graphical features for something other then making the environment prettier.

I am always interested in what features new editors and how people use them and such and if I am missing out.

> It's not clear to me why you would want your editor to run in as many environments as possible unless you're a system administrator?

All I really was trying to say is that one may find themselves in a more limited environment at some points, I was not so much thinking of remote editing for the reason you mentioned that most developers or even system admins(unless restricted for security reason or some other) can just remote in and most editors these days do this well. but in a situation where one may be installing their system or their graphics acceleration has broken for what ever reason and now one is without their trusty editor so although I hardly every use emacs in a tty or pty it's a fallback in case something goes wrong so I can fix it while still using my editor.

>that the editor can open 60,000 line code files instantaneously syntax highlight all of it using trees that are and be butter smooth and responsive the entire time I'm searching through making multi-cursor edits or moving through the file.

this definitely sounds interesting, emacs when dealing with very large log files and such is not always fantastic and some features become painfully slow or completely unusable .

Your other points on the AI features are interesting I have been using Aider and tried aidermacs but ended up going back to a shell buffer with some basic commands to switch back to the buffer and other features to control it, while in one of the code buffers. So will definitely look at some of the AI features when I give it a spin.

Try Sublime Text if you want lower RAM usage. My instance is currently sitting at ~120mb with 3 separate projects open (that does not include usage by Rust Analyzer which runs in a separate process (and tends to use GBs of RAM), but I suspect your numbers don't either)

How much of the RAM usage is by gopls (The Go LSP)?

Kind of there with you... was pretty surprised how big the surface was with Zed, and it definitely doesn't do all the things I do in Code currently.

Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what.

I dont understand the zed hype, not only the UI has tons of issues, memory usage is not that different

what about CPU usage? Overall I agree, it doesn't have enough plugins and is not well supported yet.

Yes: https://zed.dev/docs/ai/edit-prediction