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

241–250 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#241

Post by DarkUranium »

ndiddy wrote: post #82
piker wrote: post #4

Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop

Honestly I think all native GUI is in a tough spot right now. The desktop market has matured so there aren't any large companies willing to put a ton of money into new fully featured GUI libraries. What corporate investment we do see into new technologies (Electron, SwiftUI, React Native) is mainly to allow developers to reuse work from other platforms like web and mobile in order to cut costs on desktop development.…

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

Re: Zed editor switching graphics lib from blade to wgpu

#242

Post by IshKebab »

WD-42 wrote: post #64
IshKebab wrote: post #45

Earlier quoted context omitted.

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

I’m currently writing an application that uses virtual lists in GTK: GtkListView, GtkGridView, there may be others. You ruled out GTK because of its looks I guess, I’m targeting Linux so the looks are perfect.

Not just because of its looks to be fair. Not being native Rust is a pain, and GTK only really works nicely on Linux. At least without a ton of effort to fix everything (I think some apps like maybe Mypaint have done that, but I don't want to).

Re: Zed editor switching graphics lib from blade to wgpu

#243

Post by bhasinanant »

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 wider extensibility and community support without an embedded JS backend to support the existing Code plugins. That's where the real blocker is.

Re: Zed editor switching graphics lib from blade to wgpu

#244

Post by socalgal2 »

piker wrote: post #4

Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop

In my experience immediate mode guis almost always ignore internationalization and accessibility.

The thing you get by using an OS widget and putting a string in it is that the OS can interact with the string. It can read it out load, translate it, fill it in with a password, look it up in a dictionary, edit it right to left, handle input method editors whose hot keys are in conflict with app doing its own editing, etc…

There’s a reason why the most popular ImGUIs are targeted at game dev tools and in game dev uis and not end user uis

You could potentially make an Immediate mode gui that wrapped a retained gui. arguably that is what react is. From the programmers pov it’s supposed to look like imgui code all the way down. It runs into the issues of having to keep to two representations in sync. The ui represented by react and the actual widgets (html or native) and that’s where all its complications come from

Re: Zed editor switching graphics lib from blade to wgpu

#245

Post by osener »

eviks wrote: post #196
osener wrote: post #161

Earlier quoted context omitted.

> We ignore for these purposes Zed's GPUI which the Zed team has transparently, and understandably abandoned as an open source endeavour Do you have a source for this?

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

Ok so it is not going closed source, they are just going to extend it as they need to drive Zed features. Totally understandable for an in-house UI framework, this is why you’d build one yourself anyway. I can imagine maintaining backwards compatibility, doing releases, writing documentation and growing a community around it is a considerable distraction from their product work.

Re: Zed editor switching graphics lib from blade to wgpu

#246

Post by another_twist »

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…

Curious: whats your primary programming language and what sort of development do you do ? In my experience with LLMs agentic coding paired with a good IDE works wonders. Its also allows me to surgically write critical bits of code myself while outsourcing boilerplate stuff.

Re: Zed editor switching graphics lib from blade to wgpu

#247

Post by piker »

socalgal2 wrote: post #244
piker wrote: post #4

Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop

In my experience immediate mode guis almost always ignore internationalization and accessibility. The thing you get by using an OS widget and putting a string in it is that the OS can interact with the string. It can read it out load, translate it, fill it in with a password, look it up in a dictionary, edit it right to left, handle input method editors whose hot keys are in conflict with app doing its own editing, e…

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

Re: Zed editor switching graphics lib from blade to wgpu

#248

Post by verdverm »

shimman wrote: post #211
verdverm wrote: post #205

Earlier quoted context omitted.

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.

> They are talking to their users

If you only talk to the users you already have, you won't know what the users who don't use your product want. Many a project and company have peaked early for this very reason.

Re: Zed editor switching graphics lib from blade to wgpu

#249

Post by satvikpendem »

pastel8739 wrote: post #210
Aurornis wrote: post #204

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.

Yes, so I'm glad Zed at least did spend the time to reinvent the wheel, because it benefits everyone to focus on performance, not to mention we have a high quality piece of OSS at the end of it, as even if it's paused development for now, it can still be forked or otherwise iterated upon.

Re: Zed editor switching graphics lib from blade to wgpu

#250

Post by satvikpendem »

Barrin92 wrote: post #223
tptacek wrote: post #178

Earlier quoted context omitted.

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.

>What's that, doing actual work rather than labor-of-love open source stuff? except the 'labor-of-love' stuff is what set the editor apart and why real users were choosing it and the 'actual business work' the moneymen are eager about is exactly what's in every other editor and what nobody asked for

They wrote GPUI as a business decision, to focus on performance, because they knew that that would be a core differentiator to all the other IDEs out there that use Electron for example. That they also liked writing it (as a "labor of love") is incidental.
Post reply on HN