Connecting Jupyter and Theia

In a recent conversation in the JupyterLab team compass, @saulshanabrook brought up an interesting point around connecting more with the VSCode / Theia ecosystem. This seems like a really complex but important point to think about given the popularity of VSCode and the fact that it will increasingly support and extend notebook functionality. I think it is also relevant to the extent that one of Jupyter’s missions is to promote open standards, protocols, and technology across communities.

Relevant projects using VSCode/Theia

Challenges to using Theia/VSCode

Governance challenges

As others rightly pointed out, there are two big challenges to “depending” on VSCode:

  • VSCode itself is a Microsoft product, not an open project. It has a proprietary marketplace and several proprietary extensions.
  • While VSCode’s underlying components are often openly-licensed, they are generally controlled by Microsoft without a community governance model.

I think that the first challenge could be addressed by the Theia project which (to my knowledge), is a distribution of UI elements that is heavily-influenced by VSCode, but that is community-governed (as part of the Eclipse foundation) and more flexible/extensible. They also have their own “open” extension protocol to counter Microsoft’s proprietary one. Here is an interesting interview that discusses the differences between Theia and VSCode. (Note that this doesn’t resolve the second challenge listed above.)

Technical challenges

To be honest, I’m not sure what the technical challenges would be. My guess is that JupyterLab makes a lot of assumptions about Lumino (previously, Phosphor) that would be hard to disentangle. If it were only possible to have an “all or nothing” result, then this might be a significant technical undertaking. If however it’d be possible to make piecemeal connections with the Theia ecosystem, perhaps that would work.


As time moves forward, notebook support will grow and be extended in both Theia and VSCode. I think there is value in having this process done in partnership with the Jupyter community (especially at the level of standards and protocols). Beyond this, Theia is an interesting “UI Sandbox” that could be used to build Jupyter experiences in a way that streamlines with the ever-growing extension marketplace in VSCode.

I’m curious what folks think about all of this - whether they see a path towards collaborating with, or using, components in the Theia ecosystem to facilitate Jupyter experiences. Or alternatively, is the fact that Microsoft largely controls the components in that ecosystem a deal-breaker? Or are there technical blockers in Theia that would make it impossible to accomplish what Jupyter wishes to accomplish within that technical framework?


I’m not familiar with Theia’s extension model but the initial ‘Notebook UX’ in VSCode was done in the vscode-python extension but it had a lot of limitations- my understanding is that it was running Monaco in a webview and did not interact with any other VSCode extensions (see bugs like The new implementation is in VSCode proper and it sounds like it has a specific set of extension points exposed for notebooks. Changes outside of the set extension points would probably require PRs to vscode itself.

Keep in mind what functionality would be interesting in VSCode and the process to implement that functionality.


Yeah - I believe that Theia is adding support for these notebook APIs here as well:

I feel like there are two potential connection points:

  1. Build (some?) JupyterLab components on top of Theia components
  2. Help build open notebook extensions / APIs / etc in Theia

It seems like #2 is more doable. I’d love to see more notebook / data-science development in Theia that was then brought into VSCode, rather than the other way around, since Theia (to me) has a much better governance and vendor-agnostic model.

(I should also note that I am not a UI/UX person so have no idea how difficult integrating with Theia would be :sweat_smile:)