5 ms·

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

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.

readitalready 8mo ago
Can this be done on a cheap AWS EC2 instance?
- ZeroCool2u 8mo ago
  Sure it takes very little hardware power to do this, but Zed isn't actually setup for this yet. This is in theory and after a few more API's are adapted.
nu11ptr 8mo ago
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.
- ZeroCool2u 8mo ago
  Yes, but they can add a flag to switch renderers on startup like they had for blade.
- swiftcoder 8mo ago
  > they felt their native renderer on those platforms was better and less memory intensive This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way.
  - flohofwoe 8mo ago
    WebGPU has some surprising performance problems (although I only checked Google's Dawn library, not Rust's wgpu), and the amount of code that's pulled into the project is massive. A well-made Metal renderer which only implements the needed features will easily be 100x smaller (in terms of linecount) and most likely faster.
    - pjmlp 8mo ago
      There is also the issue that it is designed with JavaScript and browser sandbox in mind, thus the wrong abstraction level for native graphics middleware. I am still curious how much uptake WebGPU will end up having on Android, or if Java/Kotlin folks will keep targeting OpenGL ES.
  - deleted 8mo ago
    [deleted]
  - vitorsr 8mo ago
    Please elaborate, I am curious to why would you think WebGPU would meaningfully beat their Metal/DirectX renderers.
    - deleted 8mo ago
      [deleted]
    - swiftcoder 8mo ago
      I don't think it would, but I don't think it's a given that their homegrown renderer is wildly more performant either - people tend to overestimate the performance of naive renderers
      - ChadNauseam 8mo ago
        wgpu isn't a renderer though, it's an abstraction layer. It's honestly hard for me to imagine it ever being faster than writing directx or metal directly. It has many advantages, like that it runs in browsers and is memory safe (and in the case of dawn, has great error messages). But it's hard for it to ever be as fast as the native APIs it calls for you.
        grovesNL 8mo ago
        I think most non-trivial cross-platform graphics applications eventually end up with some kind of hardware abstraction layer. The interesting part is comparing how wgpu performs vs. something custom developed for that application, especially if their renderer is mostly GPU-bound anyway. wgpu definitely has some level of overhead, but so do all of the other custom abstraction layers out there.
  - MindSpunk 8mo ago
    WGPU is just a layer over the top of the native APIs on any given platform so unless Zed's DirectX/Metal renderers were particularly bad it's unlikely WGPU will be better here.
    - swiftcoder 8mo ago
      I'm not saying it would be better, I'm saying it may not be particularly much worse. Which still might make it worth simplifying everything by settling on one rendering abstraction
  - nicoburns 8mo ago
    > This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way. They probably will for memory usage. Current wgpu seems to have a floor around ~100mb that isn't there with other rendering backends (and it was more like ~60mb with wgpu a few months / versions ago). Not sure if this is fixable in wgpu, or do with spec compatibility (my guess would be that it's fixable, just not top priority for the team atm).
arghwhat 8mo ago
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.
nindalf 8mo ago
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.
rafaelmn 8mo ago
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.
- deleted 8mo ago
  [deleted]
- nahuel0x 8mo ago
  Zed already has a client/server editor architecture: https://zed.dev/docs/remote-development https://zed.dev/docs/remote-development
usefulcat 8mo ago
If you're talking about remote editing (editing files which reside on a remote server), Zed already supports that?
- Octoth0rpe 8mo ago
  I believe they're referring to running Zed entirely in a browser. This opens up possibilities like using zed for something like codepen, or embedding it into a git web frontend like gitea. Many projects like this basically embed vscode, a rare benefit of being an electron app which Zed is not.
  - ZeroCool2u 8mo ago
    Exactly.
ethmarks 8mo ago
A web port is apparently already on their roadmap: https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web
- ZeroCool2u 8mo ago
  I didn't realize that, super exciting!

readitalready 8mo ago

Can this be done on a cheap AWS EC2 instance?

ZeroCool2u 8mo ago
Sure it takes very little hardware power to do this, but Zed isn't actually setup for this yet. This is in theory and after a few more API's are adapted.

nu11ptr 8mo ago

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.

ZeroCool2u 8mo ago
Yes, but they can add a flag to switch renderers on startup like they had for blade.
swiftcoder 8mo ago
> they felt their native renderer on those platforms was better and less memory intensive This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way.
- flohofwoe 8mo ago
  WebGPU has some surprising performance problems (although I only checked Google's Dawn library, not Rust's wgpu), and the amount of code that's pulled into the project is massive. A well-made Metal renderer which only implements the needed features will easily be 100x smaller (in terms of linecount) and most likely faster.
  - pjmlp 8mo ago
    There is also the issue that it is designed with JavaScript and browser sandbox in mind, thus the wrong abstraction level for native graphics middleware. I am still curious how much uptake WebGPU will end up having on Android, or if Java/Kotlin folks will keep targeting OpenGL ES.
- deleted 8mo ago
  [deleted]
- vitorsr 8mo ago
  Please elaborate, I am curious to why would you think WebGPU would meaningfully beat their Metal/DirectX renderers.
  - deleted 8mo ago
    [deleted]
  - swiftcoder 8mo ago
    I don't think it would, but I don't think it's a given that their homegrown renderer is wildly more performant either - people tend to overestimate the performance of naive renderers
    - ChadNauseam 8mo ago
      wgpu isn't a renderer though, it's an abstraction layer. It's honestly hard for me to imagine it ever being faster than writing directx or metal directly. It has many advantages, like that it runs in browsers and is memory safe (and in the case of dawn, has great error messages). But it's hard for it to ever be as fast as the native APIs it calls for you.
      - grovesNL 8mo ago
        I think most non-trivial cross-platform graphics applications eventually end up with some kind of hardware abstraction layer. The interesting part is comparing how wgpu performs vs. something custom developed for that application, especially if their renderer is mostly GPU-bound anyway. wgpu definitely has some level of overhead, but so do all of the other custom abstraction layers out there.
- MindSpunk 8mo ago
  WGPU is just a layer over the top of the native APIs on any given platform so unless Zed's DirectX/Metal renderers were particularly bad it's unlikely WGPU will be better here.
  - swiftcoder 8mo ago
    I'm not saying it would be better, I'm saying it may not be particularly much worse. Which still might make it worth simplifying everything by settling on one rendering abstraction
- nicoburns 8mo ago
  > This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way. They probably will for memory usage. Current wgpu seems to have a floor around ~100mb that isn't there with other rendering backends (and it was more like ~60mb with wgpu a few months / versions ago). Not sure if this is fixable in wgpu, or do with spec compatibility (my guess would be that it's fixable, just not top priority for the team atm).

arghwhat 8mo ago

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.

nindalf 8mo ago

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.

rafaelmn 8mo ago

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.

deleted 8mo ago
[deleted]
nahuel0x 8mo ago
Zed already has a client/server editor architecture: https://zed.dev/docs/remote-development https://zed.dev/docs/remote-development

usefulcat 8mo ago

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

Octoth0rpe 8mo ago
I believe they're referring to running Zed entirely in a browser. This opens up possibilities like using zed for something like codepen, or embedding it into a git web frontend like gitea. Many projects like this basically embed vscode, a rare benefit of being an electron app which Zed is not.
- ZeroCool2u 8mo ago
  Exactly.

ethmarks 8mo ago

A web port is apparently already on their roadmap: https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web

ZeroCool2u 8mo ago
I didn't realize that, super exciting!