Virtual file system in browser?

Does Theia have a way to run in browser (not connected to any backend) with a virtual file system?

If not, is there a way to hook it to something like BrowserFS?

Please see

1 Like

Are there any existing plans?

It would be amazing to have this! Just imagine software projects take advantage of this on simple static documentation sites. They could make a virtual file system with the needed files for a demo (f.e. the demo might have an index.html file that imports some .js and .css files). Then imagine a user could play with the files and see changes to the files live (all on a static website), with the option to download a zip file containing the files in their modified state.

For example, imagine any examples from Three.js running in the Theia IDE on (to give an experience as close to VS Code or Theia on desktop).

We can do it currently if we have a backing server, but there are many projects that only have static websites for documentation and examples (like Three.js).

I cannot promise anything, it looks like there is a move in this direction, i.e. VS Code extension will support offline mode. It would require a significant effort from our side to allow to run in offline mode. But it was asked many times already, so maybe file a proposal request.

I think Theia can be tricked to thinking there is a file system. F.e. this awesome project runs full git inside Wasm (including communication to and from network for pushing and pulling):

Git, inside the environment set up by that repo, has a filesystem available to it.

Similarly, anywhere that Theia calls to a file system, we can have it call into the fake filesystem like wasm-git does.

Theia could even use wasm-git for the Source Control stuff.

In this mode, all the parts of Theia that normally communicate over network, would simply call that local file system instead.

Few limitations I see:

  • It uses emscripten FS API so it might be difficult hooking something else to it.
  • Assuming the FS is emulated and so is Git: language servers, debug adapters and VS Code extensions must run in sub-processes, which are spawned on the remote backend right now.

The idea sounds fun, but maybe a PoC could give more weight to it.

1 Like