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

171–180 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#171

Post by doodlesdev »

net_ wrote: post #145
mort96 wrote: post #133

Earlier quoted context omitted.

How's the accessibility?

I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually.

   > I don't get why every language's community doesn't just do the same thing: roll an idiomatic UI lib on top of SDL.

   > I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually.
Well, that's why :)

For most serious applications, accessibility isn't a second thought, it's a requirement and it's very hard to implement correctly.

Re: Zed editor switching graphics lib from blade to wgpu

#172

Post by drnick1 »

jauntywundrkind wrote: post #98
nmilo wrote: post #94

I find it odd the rust community feels the need to reimplement tried and tested APIs in "pure safe Rust". Like no other language has better C integration, and we have had cross-platform windowing libraries since like the 90's, why does everyone reach for a brand new unstable libraries with less maintainer support? Edit: replying to https://tritium.legal/blog/desktop , not the OP

Aside from Rust being better (impl is such a great decoupling, fearless type safety), there is afaik nothing one tenth as useful and good as cargo & is crate ecosystem (docs rs, crates.io, and all the packages). I find it odd the broader hacker community feels the need to requestion and cross-examine every choice for using rust. Like, no other language has such great just works ergonomics, with a solid language, fant…

One could argue that Rust isn't well suited for GUI development at all, where class-based OOP really shines.

Then there is the issue that the Rust community likes to rewrite classic C programs because of "memory safety" and "modern tooling," but really just focuses on the easy 80% of the work. It feels like these rewrites are more done to gain popularity on GitHub than anything, as they most often remain incomplete and never replace the original implementation.

Finally there is the GPL to MIT licensing issue, on which much has been said already.

Re: Zed editor switching graphics lib from blade to wgpu

#173

Post by qznc »

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…

Zed competes mostly against Visual Studio Code. Not against Jetbrains.

Re: Zed editor switching graphics lib from blade to wgpu

#174

Post by nu11ptr »

satvikpendem wrote: post #119
nu11ptr wrote: post #66

Earlier quoted context omitted.

While unfortunate, to me this just says any user requested features aren't going to get merged anytime soon. As is, it already runs on windows/linux/mac, and will need to do so maturely for Zed to function. Therefore, to me, this isn't that big of a deal, and when they need things like web support (on their roadmap), they will then add that. I'm curious... does anyone have any PRs or features that they feel need merg…

I recently saw a PR where the author implemented shaders but it was closed by the maintainers as the feature wasn't needed by Zed the editor.

Thanks. I probably could have answered my own question had I simply looked here:

https://github.com/gpui-ce/gpui-ce/pulls

and here:

https://github.com/zed-industries/zed/pulls?q=is%3Apr+is%3Ao...

Re: Zed editor switching graphics lib from blade to wgpu

#175

Post by dijit »

duped wrote: post #168
dijit wrote: post #87

Earlier quoted context omitted.

I partly agree, but I think you're overcorrecting. Game developers didn't invent data-oriented design or performance-first thinking. But there's a reason the loudest voices advocating for them in the 2020s come from games: we work in one of the few domains where you literally cannot ship if you ignore cache lines and data layout. Our users notice a 5ms frame hitch- While web developers can add another React wrapper a…

I don't really like this line of discourse because few domains are as ignorant of computing advances as game development. Which makes sense, they have real deadlines and different goals. But I often roll my eyes at some of the conference talks and twitter flame wars that come from game devs, because the rest of computing has more money resting on performance than most game companies will ever make in sales. Not to me…

I mean... fair point? I'm not claiming games are uniquely performance-critical.

You're right that HFT, large-scale backend, and real-time systems care deeply about performance, often with far more money at stake.

But those domains are rare. The vast majority of software development today can genuinely throw hardware or money at problems (even HFT and large backend systems). Backends are usually designed to scale horizontally, data science rents bigger GPUs, embedded gets more powerful SoCs every year. Most developers never have to think about cache lines because their users have fast machines and tolerant expectations.

Games are one of the few consumer-facing domains that can't do this. We can't mandate hardware (and attempts at doing so cost sales and attract community disgust), we can't hide latency behind async, and our users immediately notice a 5ms hitch. That creates different pressures- we're optimising for the worst case on hardware we don't control whilst most of the industry optimises for the common case on hardware they choose.

You're absolutely right that we're often ignorant of advances elsewhere. But the economic constraint is real, and it's increasingly unusual.

Re: Zed editor switching graphics lib from blade to wgpu

#176

Post by satvikpendem »

nu11ptr wrote: post #174
satvikpendem wrote: post #119

Earlier quoted context omitted.

I recently saw a PR where the author implemented shaders but it was closed by the maintainers as the feature wasn't needed by Zed the editor.

Thanks. I probably could have answered my own question had I simply looked here: https://github.com/gpui-ce/gpui-ce/pulls and here: https://github.com/zed-industries/zed/pulls?q=is%3Apr+is%3Ao...

Sadly it doesn't actually look like gpui-ce has any activity, the maintainer merged one pull request (literally, #1) and then stopped. They should've just added more community maintainers to the GPUI repo directly rather than having a fork.

Re: Zed editor switching graphics lib from blade to wgpu

#177

Post by zem »

nmilo wrote: post #94

I find it odd the rust community feels the need to reimplement tried and tested APIs in "pure safe Rust". Like no other language has better C integration, and we have had cross-platform windowing libraries since like the 90's, why does everyone reach for a brand new unstable libraries with less maintainer support? Edit: replying to https://tritium.legal/blog/desktop , not the OP

yeah, it's fine that people are experimenting with new gui toolkits from scratch but I wish gtk integration got a lot more love.

Re: Zed editor switching graphics lib from blade to wgpu

#178

Post by tptacek »

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

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.

Re: Zed editor switching graphics lib from blade to wgpu

#179

Post by norman784 »

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…

The thing with GPUI is that the library itself is very low level and their scope is limited (by design I suppose), the ui with components is a separate crate with GPL license, while GPUI license is Apache.

As far GPUI has a great foundation, the community can built the components themselves.

Re: Zed editor switching graphics lib from blade to wgpu

#180

Post by x0x0 »

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 came from nvim after using vim for decades. For me, you could approximate Zed with endless hours of tinkering in nvim, or I could just use Zed.

Things that keep me: fast. Easy project wide search that is fast. Easy file completion that is fast. Easy ability to add/remove line numbers from a gutter. Vi keys that... kinda mostly work. Sorta. Code collapsing that I didn't have to spend hours fidgeting with that also mostly works with Ruby (except for rescue clauses / end-of-function exception handling which collapses weirdly.)

Post reply on HN