Becoming a Widget Author

Over the past 2.5 years, I’ve been building a spreadsheet extension for JupyterLab called Mito. This extension needs to share state between the frontend and the backend, and also have the backend/frontend communicate constantly. As such, we naturally built Mito as a Jupyter Widget.

Being a widget comes with many benefits, including easy-to-extend templates, automatic shared state, pre-setup comm channels, and a handling of kernel restarts and page refreshes. For the first 2 years of development, widgets were perfect.

Limitations of Widgets

But recently, we've hit into some limitations of the widgets framework. Namely, opinionated state management practices, complexity with integrating with other UI libraries, additional Python dependencies, and install rates that leave a bit to be desired.

As a result of these complexities, we decided to move from being a widget to being a rich output: a javascript frontend that manually establishes comms with the Python kernel, and shares state with it.

I'll share details on how to make this transition away from widgets, and also talk about what it gives you as widget author: reduced dependencies, potentially-easier installation, more manual (but customizable) state management, and more!

Towards a Unified Rich Output

Jupyter contributors are currently exploring (https://github.com/jupyterlab/richoutput-js) a more minimial rich output interface. I’ll close by reflecting on the benefits of this more minimal interface, and why it might be the right way forward for the entire notebook ecosystem :)