The World Moves On – Jupyter Classic Notebook No Longer the MyBinder Default UI

See the official announcement here.

I’ve been tinkering with web apps and and using third party APIs for long enough now to have a sense for the lifecycle of various projects.

In the early days, things are innocent and open, and traction is often generated because its easy for folk to try things out: the frameworks are simpler and eaasier to use than previous ones, so folks use them; the APIs don’t require API keys, because no-one’s abusing them; the features are limited, because the service or app is still young, and whilst the docs may or not comprehensive, they’re still small enough to find your way around; and the relatively simplicity of the codebase (because it’s still small) means it’s not too hard to poke around to figure out to do things.

Then the project gets popular, and bigger, and more complex, and it’s harder to play with. It becomes more “enterprisey”, even if it’s still an open source project: the development environment starts to become ever more complex, the code becomes more compartmentalised and elaborate, and unless you’re working with it regularly, it can be hard to get a sensible overview of it.

And the examples often get more elaborate. The sort of examples where you already need to have a good mental model of the whole code framework to make any sense of the examples.

And as things move on, they become more exclusive. I have limited developer skills and limited time. My personal approach works for identifying early stage projects or apps that might have potential (at least as I see it). Low barrier to entry for folk who want to get stuff done with the application or package, and perhaps customise it.

When spotting new tech, new code packages, new ideas, I see if I can get something simple, but novel, working, or that perhaps solves one the dozens of things on my “it would be handy if I had a thing to do X” list, within half an hour (the half an hour is elastic up to one to two hours!)- a half hour hack. And from a standing start.

And if I can’t, then I figure it’s probably too hard for large numbers of other people to get started with too; which will limit its adoption.

And so it is with the Jupyter UIs. The classic notebook was relatively straightforward to build simple extensions for, but JupyterLab continues to be beyond me. Classic notebook is minimally maintained, but the core Jupyter developer effort in UI terms is based on JupyterLab and UIs based around that framework (such as RetroLab). There are other UIs too that better suit my needs:

• VS Code is increasingly powerful as a notebook editing and development environment (see for example the recent addition of rich visual differencing of different versions of the same notebook); VS Code can also support the creation of generated materials without the need for a code executing Jupyter back end. See for example VS Code as an Integrated, Extensible Authoring Environment for Rich Media Asset Creation.
• for authoring simple notebooks and interactive texts, the visual editor in RStudio, which looks like it will soon be split into a simpler, standalone editor, the Quarto editor, looks promising;
• the Curvenote editor is one to watch although I don’t really have a sense yet as to whether this will gain traction as a self-hosted or locally deployable UI irrespective of the viability of the hosted offering… Stencila is still also a thing, but it just never quite seems to be able to break through, and may now just be too complex to generate any momentum amongst have-a-go early adopters looking for a better way.

But the need to find an environment that works for me and that can be widely shared to others is starting to become a blocker (see OpenJALE for my current environment). It’s pressingly timely, I think, for a simple, ideally extensible, editing environment for line at a time coding that can be used to write linear instructional materials, interactive texts and generative materials (documents that embed source code to create assets such as charts, tables and interactive widgets; see for example Subject Matter Authoring Using Jupyter Notebooks).

The reason I need to start looking for a new approach is that it’s starting to look like the classic Jupyter notebook is coming to the end of general availability. The latest sign of this is the announcement that MyBinder launched environments will now, by default, be launched into the JupyterLab UI rather than the classic notebook UI.

For anyone who has repos with environments defind to use the classic notebook and notebook extensions that don’t work in JupyterLab, tweaks will need to be made to MyBinder launch buttons and URL to ensure that the URL path is set to /tree (in a launch URL: ?urlpath=/tree/ ).

Increasingly, to use the classic notebook, you’ll need to know where to find it. Because by default the assumption will be that you want to enter a complex developer environment, not a simple notebook authoring UI.

PS The Jupyter project is a fantastic initiative for making access to compute and arbitrary code execution possible. I think the classic notebook UI had a large part to play in providing an on-ramp to getting started with code for a lot of people: a clean, simple design, with a minimum of clutter and relatively easily extended and customised with simple HTML, Javascript and CSS. It has also provided a way for disciplines to bring computational approaches, particularly a line of code at a time approaches, to a wider audience through narrated and contextualised code scripts that perform particular tasks within the context of a human readable document. But the JuptyerLab UI is not that. It’s a piece of hostile architecture to pretty much everyone who isn’t a developer. You may be able to get to a notebook within the JupterLab UI. But you will have already put the fear into folk that it will be too complicated for them to understand. Making JupyterLab the default UI is off-putting to anyone who opens up the UI for the first time after hearing that Jupyter notebooks provide an “easy way” to get started with computing, because it looks just like any other terrifyingly complex IDE. Not a simple file listing and a simple Word Processor app that can execute code and display the results.