Feasible to build a secure theia-based ide where backend only supports file persistence?

I’m evaluating building a next gen “teach programming” IDE for code.org (non-profit, open source, one of the leading projects assisting with teaching programming to kids in school) around Theia.

Is there a generally secure way to build a Theia based all-client-side in-browser IDE where the backend only supports file storage? In my ideal world, I would compile/webpack a theia derived ide to a static bundle (js, css, etc) served off a CDN, and support file persistence using VSCode extensions (aka plugins) implementing FileSystemProvider and SourceControl targeted at our existing backend.

An example similar to what I’d like to build with Theia is jupyter-lite: GitHub - jupyterlite/jupyterlite: Wasm powered Jupyter running in the browser 💡

Are there any projects using this approach I could look at? Is it feasible with Theia?


I realize that a “full feature support” version with this model is a huge undertaking. But, because this is for introducing programming to beginners, I do not expect to use existing Theia extensions for debug, etc.

You can see an example of our existing “hand rolled” and quite old first-gen “IDE” here:

My initial target will be to get basically that UX, but built around Theia extensions/plugins, and using our existing backend for executing code, storing files, and an ultra basic “sort of an SCM” called backpack, all of which we already have backend support for.

After some experimentation (and checking our approaches that the arduino 2.0 IDE is using), I’m gaining confidence that Theia’s extension framework will allow me to produce a simple enough UX for my target… now I’m doing my first foray into seeing if I can run “almost backendless” (or, more specifically, re-using my existing backend).


Hey Seth,

Theia’s messaging architecture currently is heavily relying on JSON-RPC calls between the frontend and the backend. We currently have ~35 frontend services that communicate to the backend using this messaging system. These would need to be overwritten to use a different data source instead. Feasible, but probably quite a bit of effort. I believe this topic is discussing this as well.