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

261–270 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#261

Post by mercutio2 »

gigatexal wrote: post #95
the__alchemist wrote: post #93

I am confused by this without context. I have not heard of blade, but am aware that Zed built its own GUI library called GPUI. Having used Zed, this is a vote of confidence: The crate ecosystem is historically filled with libaries which try to be The future of X in rust but are disconnected from practical applications. GPUI by nature is not that; it's a UI lib built to a practical and non-trivial purpose. It sounds l…

I am one plugin away from moving to it directly instead of vscode. I really like it. It’s fast. It gets updates seemingly daily. I’ve never had it crash. It integrates LLMs well. It’s everything I wish vscode was if it were native.

I used to feel this way, then a week or two ago, after an automatic update, it started hanging. All. The. Time for me. Launching the app now frequently takes 30 seconds before it shows me the “load a git repo” screen.

Speed was its main advantage, before. It has become nearly unusable.

The price of extraordinarily rapid iteration, I suppose.

Re: Zed editor switching graphics lib from blade to wgpu

#262

Post by mercutio2 »

bhasinanant wrote: post #243

Zed is my goto editor when I'm not vibe coding, but that is rare these days. Their integration with Claude Code, etc really helped, but Antigravity completely pulled me away. And really, since they're catering to the same basic audience, the defaults should be the same as VSCode for most stuff. VSCode but performant would be an excellent pitch for the upcoming consumer RAM deficient world. Dunno how they plan to get…

I wonder if the reason that most people don’t agree with me about Antigravity is because you were used to VS Code?

For me, Antigravity is possibly the worst GUI experience I’ve had since Clippy.

It’s completely filled with arcane buttons, prompts that are effectively modal appear in at least 3 different places, it’s constantly… doing stuff, without any reference to where I should focus my attention.

I appreciate Google giving away absurdly generous quantities of tokens for FREE just to get me to use the thing, but I can’t bring myself to, because when I get into the flow of a feature with an LLM, I’m suddenly stuck and can’t figure it out.

It’s like peak Google UI for me.

Re: Zed editor switching graphics lib from blade to wgpu

#263

Post by JBits »

jsheard wrote: post #109
the__alchemist wrote: post #106

Earlier quoted context omitted.

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 underlying Vulkan API is updated constantly, the last spec update was about two weeks ago. Even if we only count the infrequent major milestone versions, Ash is still stuck at Vulkan 1.3, when Vulkan 1.4 launched in December of 2024.

What would be the best way to use Vulkan 1.4 in Rust today? Using the C headers with bindgen or writing my own vk.xml generator?

Re: Zed editor switching graphics lib from blade to wgpu

#264

Post by trcf23 »

dev_l1x_be wrote: post #147
trcf23 wrote: post #143

Earlier quoted context omitted.

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

Debug log says what about the crash?

Never thought to check the debug log.

I would say mostly with the agent panel going into panic in longer conversation or not able to proceed for some reason.

Claude code in terminal also has issues rendering. Never have that with vscode or iterm so I guess it’s zed related.

And sometime for eslint it won’t check ts errors then start adding false errors everywhere and become unusable if I don’t start over.

Re: Zed editor switching graphics lib from blade to wgpu

#265

Post by bschwindHN »

TingPing wrote: post #81
fishgoesblub wrote: post #41

I hope this can somehow improve the font situation. Even on a 1440p monitor, the fonts in Zed are much blurrier than any other editor I've used. I Can't even use bitmap fonts like VSCode.

From what I see wgpu isn’t using the same font stack as chromium. I think the Rust community would be against those dependencies. You can just convert bitmap fonts, supporting them doesn’t make sense in 2026.

wgpu is an API for rendering stuff on the GPU, it has no concept of font stacks or text rendering.

Re: Zed editor switching graphics lib from blade to wgpu

#266

Post by grovesNL »

ChadNauseam wrote: post #226
swiftcoder wrote: post #89

Earlier quoted context omitted.

I don't think it would, but I don't think it's a given that their homegrown renderer is wildly more performant either - people tend to overestimate the performance of naive renderers

wgpu isn't a renderer though, it's an abstraction layer. It's honestly hard for me to imagine it ever being faster than writing directx or metal directly. It has many advantages, like that it runs in browsers and is memory safe (and in the case of dawn, has great error messages). But it's hard for it to ever be as fast as the native APIs it calls for you.

I think most non-trivial cross-platform graphics applications eventually end up with some kind of hardware abstraction layer. The interesting part is comparing how wgpu performs vs. something custom developed for that application, especially if their renderer is mostly GPU-bound anyway. wgpu definitely has some level of overhead, but so do all of the other custom abstraction layers out there.

Re: Zed editor switching graphics lib from blade to wgpu

#267

Post by nu11ptr »

tuzemec wrote: post #258
nu11ptr wrote: post #136

Earlier quoted context omitted.

Thanks. Have you used cursor or copilot (recently, tab completion has gotten better)? I'm curious how this compares in actual performance. Last time I used Zed, this was a showstopper as the completions were much worse (though if I configure it to use copilot as my source, I guess it should perform the same as VsCode?).

Personally, I don't like this autocomplete or tab-completion thing. I find it very distracting. I understand why someone might like it, but it's just not my thing. I mostly use Claude (and Codex) through ACP in Zed. My colleagues use Cursor and VSCode, and I don't feel like I'm missing anything at all.

I am primarily using Claude as well, but I still have my old fix from Cursor, and as long as it is accurate like Cursor, I like it, if it falls below that level of accuracy, I find it annoying.

Re: Zed editor switching graphics lib from blade to wgpu

#268

Post by iamnbutler »

piker wrote: post #10
nu11ptr wrote: post #9

Earlier quoted context omitted.

Really? It seems better than ever to me now that we have gpui-component. That seems to finally open doors to have fully native guis that are polished enough for even commercial release. I haven't seen anything else that I would put in that category, but one choice is a start.

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.

They haven't. They are just heads down on other work. It wouldn't make sense for them to abandon it - they have no alternative. What that message was about was supporting _community_ prs and development of gpui.

Focus ebbs and flows at Zed, they'll be back on it before long.

Re: Zed editor switching graphics lib from blade to wgpu

#269

Post by iamnbutler »

satvikpendem wrote: post #252
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…

You might also want to look into Dioxus Native as it's doing a lot of what you're interested in too, with taffy and vello for example. The gaps I see in the Rust UI ecosystem as you asked are that I want a true cross platform solution for mobile, web, and desktop while most focus only on desktop, as I use Flutter currently for this purpose but need to pull in Rust crates through an FFI layer like flutter_rust_bridge,…

Cool, I'll take a look.

gpui will support web eventually - we always planned it, and i've tinkered with some folks on the team on it a bit. The problem is the crate needs to split into core/web/native (and maybe mobile?) as web needs a new executor and native has a number of deps that won't play nice with wasm...

someone did get a very claude-driven demo of gpui on the web up (you can find it in the discord somewhere.)

I would love that too though, a true cross platform solution.

> How was it like working at Zed? Any reason for leaving?

Working at Zed was great. I was employee #4 (#1 after the founders) - it was fun, often hard - Nathan & co helped me learn Rust and I fell in love with it.

I wanted to do something pretty specific (tl;dr, basically skunkworks type work) which was the reason I left.

There are always pros and cons to every role, but I appreciate that Zed is building from the ground up. DeltaDB will be very exciting - we were sitting on our hands waiting for it for a lot of the really exciting things we wanted to do with Zed.

Having to take on investors is never awesome - but as much as I don't like it, I do doubt Zed would never have existed without them.

But yeah, getting paid to design and write rust UI every day was a blast.

Re: Zed editor switching graphics lib from blade to wgpu

#270

Post by iamnbutler »

atombender wrote: post #38
nu11ptr wrote: post #9

Earlier quoted context omitted.

Really? It seems better than ever to me now that we have gpui-component. That seems to finally open doors to have fully native guis that are polished enough for even commercial release. I haven't seen anything else that I would put in that category, but one choice is a start.

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…

I do think gpui needs a native input element (enough that I wrote one (https://github.com/zed-industries/zed/pull/43576) just before they stopped reviewing gpui prs) but outside of that I think it is pretty ok and cool that gpui just exports the tools to make whatever components you need.

I could see more components being shipped first party if the community took over gpui, or for some crazy reason a team was funded to develop gpui full time, but developing baseline components is an immense amount of work, both to create an maintain.

Buttons (any div can be a button), clipboard, scroll views (div, list, uniform_list) should all already be in gpui.

Post reply on HN