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

301–310 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#301

Post by bmitc »

Matl wrote: post #288
bmitc wrote: post #272

Earlier quoted context omitted.

> as I was looking forward to using GPUI in future applications and comparing it to EGUI. I have asked online in several places for someone to compare who's used both, but I believe this to be a small pool. I have yet to learn GPUI, but I have used Egui and really like it. I was turned off of GPUI from being forced to have to install Xcode to use it on macOS, which is a major bummer, in my opinion.

Iced.rs is also neat[0]. 0 - https://github.com/iced-rs/iced

Iced indeed seems very neat. Egui is developed by a single person and so is Iced. The difference is that Egui has been quite stable whereas Iced has gone through several rewrites, as far as I can tell. It's why I didn't dive into it more, even though I like how Iced looks and focuses on the Elm model.

The Iced developer is quote open regarding his goals, which is appreciated. So while it's a nice library, it's a hard one to adopt.

https://book.iced.rs/philosophy.html

Re: Zed editor switching graphics lib from blade to wgpu

#302

Post by bmitc »

IshKebab wrote: post #45
paddy_m wrote: post #30

Earlier quoted context omitted.

I'd love to read a writeup of the state of Rust GUI and the ecosystem if you could point me at one.

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…

What's wrong with egui's virtual lists? It has support for them. https://docs.rs/egui/0.25.0/egui/containers/scroll_area/stru...

Unfortunately, it seems GPUI is no longer in development.

Iced looks great, but the developer is very open about it being a personal project (https://book.iced.rs/philosophy.html). That is appreciated, but for companies or even individuals wanting to adopt it, it's a big hurdle to get across.

Re: Zed editor switching graphics lib from blade to wgpu

#303

Post by WD-42 »

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

Earlier quoted context omitted.

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

Def agree. It feels unnatural to be using gobject in Rust. Refcell everywhere. But the end result (at least on Linux) is fast, well integrated and looks nice.

Re: Zed editor switching graphics lib from blade to wgpu

#304

Post by staticassertion »

bmitc wrote: post #300
staticassertion wrote: post #295

Earlier quoted context omitted.

I mean, in the sense that they are VC funded and so I guess you can tie anything back to VCs? You could just as easily say it has something to do with the founders mother, who gave birth to them.

No, I don't think you could easily say that. You can't say it literally has nothing to do with VCs when VCs are the only reason they're able to keep operating financially.

The founder's mother is the only reason they're able to operate at all.

If you want to talk about the VC I think you'll need to get more specific.

Re: Zed editor switching graphics lib from blade to wgpu

#305

Post by bmitc »

staticassertion wrote: post #304
bmitc wrote: post #300

Earlier quoted context omitted.

No, I don't think you could easily say that. You can't say it literally has nothing to do with VCs when VCs are the only reason they're able to keep operating financially.

The founder's mother is the only reason they're able to operate at all. If you want to talk about the VC I think you'll need to get more specific.

What are you even talking about?

Re: Zed editor switching graphics lib from blade to wgpu

#306

Post by stouset »

I just did a quick once-over on the PR and am pretty shocked by how "simple" it is. For switching the background graphics library, I would have expected this to be some pretty delicate surgery. But the "meat" is swapping out the old abstraction layer for the new one (500–600LOC) then `s/blade/wgpu/g`. There's a little more to it than that, but not much.

I'm already a Zed user, but to me that's an extremely good indicator of the engineering quality of the project.

Re: Zed editor switching graphics lib from blade to wgpu

#307

Post by staticassertion »

bmitc wrote: post #305
staticassertion wrote: post #304

Earlier quoted context omitted.

The founder's mother is the only reason they're able to operate at all. If you want to talk about the VC I think you'll need to get more specific.

What are you even talking about?

I really couldn't have been clearer. The implication was that Zed made a decision because of pressure from a VC. I said that they were vastly overestimating the pressure a VC can exert on an early stage company.

You've then pointed out that the company is directly tied to the VC, which is true but just as relevant as saying that the company is tied to the founder's parents. You've failed to explain what different there is between the VC and a parent other than that there's a causal link in the existence of the company.

So I suggested that you substantiate that difference if you want to make a point about the VC.

I don't know what is confusing about this.

Re: Zed editor switching graphics lib from blade to wgpu

#308

Post by lioeters »

DarkUranium wrote: post #241
ndiddy wrote: post #82

Earlier quoted context omitted.

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

> make it a native library that can compile to the web (using actual DOM/HTML elements there, not canvas/WebGL/WGPU)

How interesting to hear. I've been exploring a way to write cross-platform GUI apps in C, using the Sokol library and possibly DearImgui. It's very convenient how it can build to WebAssembly and run the same way as the native app. But for larger canvas sizes it does eat more processing power, more than a typical website, and I was considering using DOM elements instead of canvas.

Good point about better accessibility too, and leveraging the feature set of modern web browsers.

A cross-platform GUI library that works with native and the web, so that the same application can be built for these targets with minimal changes. With the maturity and adoption of Wasm, I expect we'll see growing development in this direction. And some people have cautioned that treating the web as a blob of canvas and compile target to deploy opaque binaries is a step back from the potential of the web, like seeing the source (or source map at least), consistent handling of text, scrolling, accessibility features.

So I like your idea to "flip the script", I think in my own way I'm finding a similar approach.

Re: Zed editor switching graphics lib from blade to wgpu

#309

Post by chiffaa »

badhorseman wrote: post #68
chiffaa wrote: 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

My tone probably came off as antagonistic and that was not my intention. I was interested in if anyone was using the high fidelity graphical features for something other then making the environment prettier. I am always interested in what features new editors and how people use them and such and if I am missing out.

From this perspective - not sure, to be honest. For me an important factor was that Zed is getting way more love from its devs than my old editor of choice Helix. But also not being constrained to a cell grid is very nice in terms of readability to me.

One thing that Zed doesn't solve but likely will is that I found "jump to label" style of features (I think flash.nvim is the closest for neovim?) is almost unreadable to me with inlined labels, but that's so highly specific I'm almost willing to live with it

Re: Zed editor switching graphics lib from blade to wgpu

#310

Post by grub5000 »

mercutio2 wrote: post #261
gigatexal wrote: post #95

Earlier quoted context omitted.

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.

FWIW I think I was experiencing the same hangs as you, and they seem to have resolved on their own now. Worth checking again just in case
Post reply on HN