Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

231–240 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#232

Earlier quoted context omitted.

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.

Isn’t the thing that differentiates zed actually largely its performance? Using electron or GTK or whatever would not differentiate it in this way.

They're switching to wgpu (another performant Rust library), not GTK or electron

Re: Zed editor switching graphics lib from blade to wgpu

#233

Earlier quoted context omitted.

Isn’t the thing that differentiates zed actually largely its performance? Using electron or GTK or whatever would not differentiate it in this way.

They're switching to wgpu (another performant Rust library), not GTK or electron

I think the parent meant that Zed could not have used an established UI library like GTK or Electron since performance was such a big focus of the editor.

Re: Zed editor switching graphics lib from blade to wgpu

#234
post #69

Earlier quoted context omitted.

I wanted to check the hype, so I installed Zed and opened a go project. Ram usage: VS Code 580 MB Zed 410 MB I don't see a reason yet to switch away from VS Code, more feature complete and I don't care about scroll speed, it's good enough in vs code.

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

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

LSPs, they are snagging the LSPs made by other developers for languages you are using. if you install any LSP or language support in VSCode its running the same thing. It only installs when you are using a language that has default support such as Rust, Python (which I believe uses a Node.js LSP), Go (same as Python), etc.

Re: Zed editor switching graphics lib from blade to wgpu

#235
post #192

Earlier quoted context omitted.

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?

Yes, and I believe the main developer works for Kraken who use it for one of their apps.

Re: Zed editor switching graphics lib from blade to wgpu

#236
post #69

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.

I wanted to check the hype, so I installed Zed and opened a go project. Ram usage: VS Code 580 MB Zed 410 MB I don't see a reason yet to switch away from VS Code, more feature complete and I don't care about scroll speed, it's good enough in vs code.

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)

Re: Zed editor switching graphics lib from blade to wgpu

#237

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…

> 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

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.

Re: Zed editor switching graphics lib from blade to wgpu

#238

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.

What is the debt? As a user, Zed feels more like the only IDE that isn't weighed down with debt. It's incredibly fast, responsive, stable, and it's iterated on very quickly.

Re: Zed editor switching graphics lib from blade to wgpu

#239
post #69

Earlier quoted context omitted.

I wanted to check the hype, so I installed Zed and opened a go project. Ram usage: VS Code 580 MB Zed 410 MB I don't see a reason yet to switch away from VS Code, more feature complete and I don't care about scroll speed, it's good enough in vs code.

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

Currently Zed uses more CPU than VSCode on my Windows and macOS laptops.

Re: Zed editor switching graphics lib from blade to wgpu

#240

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.

Early Zed user here. There’s a lot of small things you’ll hit if you use Zed where it’s a subtlety nicer design point, but one of the big ones for me is project-wide search. Zed’s multibuffers are SO much better than VS Code’s equivalent. If I’m debugging something on a coworkers laptop, VSCode is mostly usable until I hit that. If you’re a craftsman, it’s worth trying different tools!

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.
Post reply on HN