Hiya, I'm Nate! I'm the CTO at Mito (https://trymito.io), where we've been building an open-source spreadsheet extension for Jupyter for the past two years, with the goal of reducing the barriers to entry for new Python programmers. I'm passionate about supporting OSS, building a healthy startup ecosystem within the Jupyter community, and rich outputs cells!
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.
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 :)