Why we are excited about JupyterLab 3.0 dynamic extensions!

@tonyfast @goanpeca @echarles @ericdatakelly


At Quansight, we’ve been hosting a series of live streams that feature our talented open source developers talking about the software they contribute to and the communities around them. During a recent quirkshop our incredible JupyterLab developers got together to discuss the upcoming major version changes to JupyterLab. We discussed the toil that core developers are investing to improve the experience of JupyterLab not only for developers but for users as well.



The extension system is a central concept to JupyterLab; all of the features (e.g., notebook editor, file browser, menus, and status bar elements) are extensions that interface into the greater JupyterLab ecosystem. The core extensions that ship with JupyterLab that establish the baseline JupyterLab interface. Third-party community extensions can then be installed to enhance and augment the user experience. This model allows for development to happen inside the tool itself, and co-development to happen by the surrounding ecosystem.


Very soon, JupyterLab will be achieving a major milestone by upgrading from version 2 to 3. The next few sections will highlight the impacts of this upgrade from individual and organizational perspectives.



JupyterLab extensions ecosystem


JupyterLab version 2 was a landmark in the interactive computing development phase. During its time, the extensions ecosystem flourished. There are now extensions for interacting with big data (e.g., Dask, HoloViz), collaborating with others (e.g., jupyter-videochat), and customizing styling. These connections are possible only because JupyterLab connected modern, performant JavaScript with scientific computing interfaces that improved users’ abilities to communicate and collaborate. The development during this phase proved the extensibility of