Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

Post reply on HN
Print view View original

201–210 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#201

Post by EnergyAmy »

iamnbutler wrote: post #191
iamnbutler wrote: post #187

Earlier quoted context omitted.

I started the gpui-ce fork but I'm becoming somewhat more interested in a fresh framework that is more aligned with the rust ecosystem in general - using crates like glam/glamour, parley, palette, etc Lots of gpui was built with build Zed/a text editor in mind directly, and as folks have mentioned here, it is hard for Zed Industries to justify work on gpui that is purely for the community. Nathan is usually pretty pr…

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.

Iced is promising, using it for a small side project. Fairly straightforward and easy to use, but lacking basic things from more mature libraries (unsurprisingly, since it's still early). If you want something like a QTreeView for example, you're on your own. It's cool that it supports WASM, though I'd call it alpha support for now.

Re: Zed editor switching graphics lib from blade to wgpu

#203

Post by throwa356262 »

chiffaa wrote: post #59
badhorseman wrote: post #50

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.

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

Re: Zed editor switching graphics lib from blade to wgpu

#204

Post by Aurornis »

laweijfmvo wrote: post #104
satvikpendem wrote: post #42

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

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.

Re: Zed editor switching graphics lib from blade to wgpu

#205

Post by verdverm »

stephc_int13 wrote: post #202

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

Re: Zed editor switching graphics lib from blade to wgpu

#206

Post by throwa356262 »

eklavya wrote: post #69
badhorseman wrote: post #50

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.

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

Re: Zed editor switching graphics lib from blade to wgpu

#207

Post by xyzsparetimexyz »

flohofwoe wrote: post #32

Seeing that the author of Blade (kvark) isn't exactly a 3D API newbie and also worked on WebGPU I really wonder if a switch to wgpu will actually have the desired long term effect. A WebGPU implementation isn't exactly slim either, especially when all is needed is just a very small 3D API wrapper specialized for text rendering.

Cross API graphics abstractions are almost always a bad idea even if its just wrapping modern DX12 and Vulkan, and always always are when Metal comes into the mix.

Re: Zed editor switching graphics lib from blade to wgpu

#208

Post by meindnoch »

kllrnohj wrote: post #96
pjmlp wrote: post #21

Earlier quoted context omitted.

Interesting read, however as someone from the same age group as Casey Muratori, this does not make much sense. > The "immediate mode" GUI was conceived by Casey Muratori in a talk over 20 years ago. Maybe he might have made it known to people not old enough to have lived through the old days, however this is how we used to program GUIs in 8 and 16 bit home computers, and has always been a thing in game consoles.

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

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

That's exactly what they did :D

Re: Zed editor switching graphics lib from blade to wgpu

#209

Post by xyzsparetimexyz »

flohofwoe wrote: post #19
conorbergin wrote: post #11

Is webgpu a good standard at this point? I am learning vulkan atm and 1.3 is significantly different to the previous APIs, and apparently webgpu is closer in behavior to 1.0. I am by no means an authority on the topic, I just see a lack of interest in targeting webgpu from people in game engines and scientific computing.

For a text editor it's definitely good enough if not extreme overkill. Other then that the one big downside of WebGPU is the rigid binding model via baked BindGroup objects. This is both inflexible and slow when any sort of 'dynamism' is needed because you end up creating and destroying BindGroup objects in the hot path. Vulkan's binding model will really only be fixed properly with the very new VK_EXT_descriptor_hea…

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.

Re: Zed editor switching graphics lib from blade to wgpu

#210

Post by pastel8739 »

Aurornis wrote: post #204
laweijfmvo wrote: post #104

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

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