An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.
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.
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.
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.
A web port is apparently already on their roadmap: https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web
If you're talking about remote editing (editing files which reside on a remote server), Zed already supports that?
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.