Do you need a backend server to run VSCode in the browser?

[mattfysh]

As titled. Why is a backend server necessary? In theory, VSCode's web layer could be componentized, and backend communication replaced with in-browser APIs that interact with in-browser storage, e.g. IndexDB.

Is this possible?
If not, why?
If so, how can it be done?

[code-asher]

Definitely doable.

In fact, our first iteration of code-server essentially did this. We shimmed the Node API so extensions and the entirety of VS Code could run directly in the browser. In our case we made those API calls go out to the server but they could just as easily have been made to use browser storage, etc.

When VS Code came out with their web stuff we abandoned our initial implementation simply because it was less maintenance.

This method could still be used today to run the non-web version of VS Code in the browser. It could also be used with the web version although some additional changes would need to be made. Something like:

1. Run backend in a web worker
2. Run spawned processes in a web worker (like the extension host)
3. Shim Node API in those web workers
4. Refactor web layer to communicate with the web workers instead of a server

[jsjoeio]

Maybe this project could be of interest? https://github.com/glenstack/vscode-workers

[mattfysh]

I've got the web version of VSCode working (via yarn run web), I'm just struggling to figure out where I need to intercept the browser calls so I can replace with my own implementation. I'm sure there's documentation somewhere but I just can't seem to find it.

It looks like the entry point I'm after is the create method in https://github.com/microsoft/vscode/blob/main/src/vs/code/browser/workbench/workbench.ts

The other file I'm trying to sift through is https://github.com/microsoft/vscode/blob/main/src/vs/workbench/workbench.web.api.ts

Hoping something springs up soon! Would be great to treat the vscode as a black box as much as possible and learn just the the pieces needed from the Workbench API