Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

211–220 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#211

Zed seems to be already suffering from heavy technical debt. From my perspective, as a game dev, their stack is a lot heavier than it should be.

That happens when you don't talk to enough users, build the wrong things, and then iterate like a good startup. It compounds Building a chat platform in an IDE with CRDTs...? That screams we are more interested in the solutions than the problems, and that they didn't appreciate network effect before attempting this

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.

Re: Zed editor switching graphics lib from blade to wgpu

#212
post #59

Earlier quoted context omitted.

A lot of people use VSCode. Zed's value proposition is being basically that but with fully native code, so without the madness that is Electron. If you're not a fan of this kind of tooling, it's totally fine, but many people see the value in having an extensible graphical code editor

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).

Zed us, in fact, fully native. It's top-to-bottom Rust, which gives them C++ equivalent speeds or better compiles to native code and lets them much more easily make use of multi-threading parallelism than basically any other language that compiles to a static binary. They also use a custom GUI framework built from the graphics driver's up to be maximally efficient, performance smooth and low latency; that's literally the subject of this thread!

The only reason it would be spawning Node.js processes is if it's running a javaScript/typescript language server for you, but that's not a property of Zed itself, it's something any other editor would do (including VS Code). Also, the resident memory of Zed, even with multiple entire projects with hundreds of tabs open, running several language servers and multiple terminals and AI agents for me never exceeds about 900 megabytes, which is significantly less than VS Code uses even at startup.

Whatever it was that you ran into, it's likely some kind of fluke or platform-specific bug.

Re: Zed editor switching graphics lib from blade to wgpu

#213

An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.

A web port is apparently already on their roadmap: https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web

I didn't realize that, super exciting!

Re: Zed editor switching graphics lib from blade to wgpu

#214

Earlier quoted context omitted.

> We gotta focus on some business relevant work in 2026 Remember that post announcing the millions of VC capital they raised? This is the result

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.

IMGUI and other GPU accelerated toolkits exist and have been created without billons of VC revenue.

In fact the entire Qt group is just work 650m EUR

Re: Zed editor switching graphics lib from blade to wgpu

#215

Zed also stopped GPUI (their GPU accelerated Rust UI framework) development for now, sadly. > Hey y'all, GPUI develoment is getting some major brakes put on it. We gotta focus on some business relevant work in 2026, and so I'm going to be pushing off anything that isn't directly related to Zed's use case from now on. However, Nate, former employee #1 at Zed, has started a little side repo that people can keep iterati…

Iced.rs is probably the better UI library anyways in the long run as it’s backed by a major hardware vendor. https://iced.rs

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.

Re: Zed editor switching graphics lib from blade to wgpu

#216

Switched from Intellij (various) to Cursor because of AI integration, only using Claude Code CLI, switched to VS because Cursor became so annoying every release, pushing their agents down my throat, activating what I did deactivate every release, recently thought "Why do I even use that slow bloated thing of VS?" and switched to Zed. Very happy camper. So much faster. So much snappier. Would love Claude Code CLI inte…

Yep. Zed is the best. It’s in an optimum spot for me. It’s super snappy and has good implementation of vim keybindings for manual coding, and it has appropriate AI integration that does all the AI stuff I want without being in my face about how AI it all is.

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

Re: Zed editor switching graphics lib from blade to wgpu

#217

The Zed editor seems kind of silly to me. I would rather my editor works in many possible environments maybe even one that only has a tty interface. What advantages are people finding with this editor other then high fidelity scrolling.

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? Generally, most of us do our serious coding work on the major OS platforms and we would want a native editor that takes advantage of those platforms and the hardware they tend to run on maximally; if we need to edit something on some other box elsewhere, we could either use Zed's remote development system or just use MicroEmaca Nano or VI depending on which key bindings were used to.

The advantage I find personally, at least compared to something like emacs, is not just that you get high fidelity scrolling, but 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. As well as being able to open for instance log files that are multi-megabytes large without having to worry about anything.

Plus, Zed has a lot of refinements and features over other editors, even if you discount the benefits of GPUI. I've spoken at length before about why I think its approach to coding agents is the best at sort of enhancing the human in the loop and keeping you in a flow state and preventing skill degradation[0], but I also think the range and design of the editing actions are better than almost all modern text editors, closer to what something like Emacs provides, and the UI is overall more streamlined and pleasant to use than something like VS Code, even though it's generally the same philosophy. There's also the collaboration features and the edit predictions.

[0]: https://news.ycombinator.com/item?id=46995110

Re: Zed editor switching graphics lib from blade to wgpu

#218

Earlier quoted context omitted.

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.

IMGUI and other GPU accelerated toolkits exist and have been created without billons of VC revenue. In fact the entire Qt group is just work 650m EUR

Who said anything about billions? I just said that it costs money to pay people to work on OSS, which is accurate as ImGui is sponsored by companies and Qt is a commercial entity with infamous licensing. VC doesn't necessarily mean billions in funding.

Re: Zed editor switching graphics lib from blade to wgpu

#219
post #192

Earlier quoted context omitted.

Iced.rs is probably the better UI library anyways in the long run as it’s backed by a major hardware vendor. https://iced.rs

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 comm…

Isn't System76 supporting and contributing to iced?

Re: Zed editor switching graphics lib from blade to wgpu

#220
post #94

I find it odd the rust community feels the need to reimplement tried and tested APIs in "pure safe Rust". Like no other language has better C integration, and we have had cross-platform windowing libraries since like the 90's, why does everyone reach for a brand new unstable libraries with less maintainer support? Edit: replying to https://tritium.legal/blog/desktop , not the OP

GUI is much more than just cross platform windowing. Which fwiw, is a mostly solved problem in Rust - there's not a bunch of reimplementation or instability. The ecosystem is solidified behind winit (*).

Also, we don't have good cross platform desktop GUI libraries in C. That's why everyone started using Electron.

(*) with some small exceptions

Post reply on HN