Can this be done on a cheap AWS EC2 instance?

From the PR, it sounds like the switch to WGPU is only for linux. The team was reluctant to do the same for macOS/Windows since they felt their native renderer on those platforms was better and less memory intensive.

Well, not really. It means you have a renderer that is closer to being portable to web, not an editor that will run in web "with some additional work". The renderer was already modular before this PR.

Quoting maddythewisp from that PR:

> There is significant work beyond the renderer that would need to happen to run Zed in a browser - notably background tasks and filesystem/input APIs would need web/wasm-compatible implementations.

Rendering in the browser has nothing to do with being able to do remote editing like you can in VSCode - you would just be able to edit files accessible to the browser.

Just like you can hook up local VS code native up to a random server via SSH, browser rendering is just a convenience for client distribution.

You would need a full client/server editor architecture that VS code has.

If you're talking about remote editing (editing files which reside on a remote server), Zed already supports that?

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.

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.

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

Can I humbly ask how are LLMs and Rust GUIs related?

This is why I'm using LLMs to help me hand code the GUI for my Rust app in SDL2. I'm hoping that minimizing the low-level, drawing-specific code and maximizing the abstractions in Rust will allow me to easily switch to a better GUI library if one arises. Meanwhile, SDL is not half bad.

> Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented.

Down the stack, low-level 3D acceleration is in a rough spot too unfortunately. The canonical Rust Vulkan wrapper (ash) hasn't cut a release for nearly two years, and even git main is far behind the latest spec updates.

[delayed]

I don't feel like having one main library for creating windows it's bad, I feel like that way the work gets shared and more collaboration happens

I don't know why Blade was decided on, but it was started by Kvark who worked on WGPU for Mozilla for some time. I assumed it would be a good library on that basis.

It's a good standard if you want a sort of lowest-common-denominator that is still about a decade newer than GLES 3 / WebGL 2.

The scientific folks don't have all that much reason to upgrade from OpenGL (it still works, after all), and the games folks are often targeting even newer DX/Vulkan/Metal features that aren't supported by WebGPU yet (for example, hardware-accelerated raytracing)

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_heap extension (https://docs.vulkan.org/features/latest/features/proposals/V...).

Bevy engine uses wgpu and supports both native and WebGPU browser targets through it.

The WebGPU API gets you to rendering your first triangle quicker and without thinking about vendor-specific APIs and histories of their extensions. It's designed to be fully checkable in browsers, so if you mess up you generally get errors caught before they crash your GPU drivers :)

The downside is that it's the lowest common denominator, so it always lags behind what you can do directly in DX or VK. It was late to get subgroups, and now it's late to get bindless resources. When you target desktops, wgpu can cheat and expose more features that haven't landed in browsers yet, but of course that takes you back to the vendor API fragmentation.

The old graphics library was basically unmaintained; bug fix PRs were being ignored. WGPU is very actively maintained.

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 merging in order to use GPUI in their own projects? (other than web support)

Early Zed user here.

There’s a lot of small things you’ll hit if you use Zed where it’s a subtlety nicer design point, but one of the big ones for me is project-wide search. Zed’s multibuffers are SO much better than VS Code’s equivalent.

If I’m debugging something on a coworkers laptop, VSCode is mostly usable until I hit that.

If you’re a craftsman, it’s worth trying different tools!

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