I’m an active contributor to Theia, an open source framework for creating web based IDEs. See our official website, if you are interested in more information.
Currently, Theia uses phosphorjs for window management. Although phosphorjs has served us well, its maintenance has ceased, leading to tech debt in our code base. For example, we’ve had to implement patches for multi-window support during our build process, highlighting the need for a more sustainable solution.
In our search for alternatives, Lumino has emerged as a prime candidate. In fact, we already have a POC in which we successfully transitioned from phosphorjs to Lumino.
We view this potential adoption as a collaborative opportunity. The Theia community has a good track record of contributing back to adopted technologies.
We therefore wanted to discuss some topics with the community:
Would the Jupyter/Lumino community be interested in Theia as a new adopter of Lumino, especially given that our use case extends beyond Jupyter’s primary focus?
Are there any concerns or considerations, such as future plans that might affect Lumino’s longevity, that we should be aware of?
How open would the Lumino community be to contributions from Theia developers?
If I posted in the wrong community or you would prefer another communication channel, please let me know
I can’t speak for everyone on the lumino team, but I think generally:
@lumino isn’t going anywhere anytime soon
more adopters are good!
any contributions that don’t negatively impact the JupyterLab+Notebook developer/user experience would be welcome.
probably the most likely red flags would be
novel non-@lumino runtime dependencies
significant degradation of any of performance, correctness, or accessibility
This forum is a fine place to discuss. For a higher-bandwidth interface, 99% of lumino maintainers are involved in JupyterLab, and usually at least someone attends the Wednesday-ly JupyterLab call, which can be found on the community calendar.
Below are some personal thoughts, based on discussions over time…
Some things starting to bubble up would be around a long-term (future) standards alignment effort, replacing lumino-specific concepts with their standards-based counterparts.
At some point it would be conceivable that the “puts DOM on page” part of lumino Widgetmight at some point be handled by Web Components, once some of the remaining pieces are squared away. In this case, standards are great, but on jupyterlab, we’ve seen some growing pains working through the composability and accessibility challenges that come with adopting this technology. It’s possible a lumino-specific registry and approach might need to come into existence. Lumino would almost certainly not use one of the existing frameworks (e.g. fast, polymer, lit), whatever is done would have to play nice-nice with other component frameworks due to the underlying singleton nature of the CustomElementRegistry.
If JS Signals ever make it through TC39 and end up on the standards track, these might be adopted by/instead of lumino Signal, which would definitely be breaking. As that might take… a while… there have been some discussions of signals growing an alternate, standards-based async iterator API, which could be phased in without breaking .connect… though this feature has no built-in API for cancellation, so .disconnect (or equivalent) might still be needed.
While commands have describedBy, the specification language is not defined. If a “final” JSON Schema specification were to land, it’s theoretically possible this could become a baseline opinion, even if a choice of a validator was not.
Finally, as JS importmap (and the related scoped adopted style sheets) is now widely-supported enough that the Application plugin system could theoretically start using module names instead of runtime tokens, but very little effort has been put towards this at any level, to my knowledge.
