search

observablehq / observable-jupyter

This repository has been archived. Please see the fork maintained by Thomas Ballinger.
https://github.com/thomasballinger/observable-jupyter
ISC License
4 stars 0 forks source link

Embed UI that looks good in every frontend #11

Open thomasballinger opened 4 years ago

thomasballinger commented 4 years ago

Jupyter is an ecosystem. There are a variety of frontends that render and execute .ipynb files, and our embed should look reasonable in all of them. In most cases, it should be enough to make sure our embed looks good in the default Jupyter Notebook view and Colab, but this issue describes the full scope of the issue.

Frontends

The most important frontend is the Jupyter Notebook. image

Jupyter notebooks are mostly run locally on a user's computer, sometimes on a remote machine where the data they're investigating lives. Companies and institutions use tools like JupyterHub to launch shareable notebooks remotely. MyBinder is a public instance of JupyterHub that lets folks run Jupyter kernels for free.

Somewhat less popular (mostly popular among power users) but also part of the Jupyter project is JupyterLab. It's pretty similar, now that we use an iframe the html differences don't matter. image

Google's Colab is the most popular proprietary frontend. Critically, it's free and has Google infrastructure behind it; for users, this means notebooks launch faster and collaboration is easier (save to Google Drive, export to GitHub, etc). Places like UC Berkeley run their own JupyterHub server for student notebooks. Places like UC Santa Cruz use Colab. Colab is huge in education. image

Colab already sandboxes output content in an iframe.

Right now we need to add more right margin to the embed in colab: image

CoCalc is another proprietary frontend. The big value add here is collaborative editing. image

There are a bunch of other hosting providers: AWS Sagemaker, DeepNote, Jovian.ml, Saturn Cloud; I think Periscope offers notebooks, Mode Analytics does too. Generally these hew to the open source Jupyter UI, so if we can nail that one we're set.

Finally there are render-only approaches, often utilizing nbconvert behind the scenes. GitHub's ipynb previewer doesn't run notebook JavaScript at all, but other tools like nbpreview should render notebooks just as they would be rendered in Jupyter notebook. image If we were being fancy we could include an image or other cached output, but it's more consistent for now to just not render in no-JavaScript environments like GitHub previews.

Embed creation time vs render time

When a Jupyter cell is executed, it produces the HTML, JavaScript, CSS that we use to render our embed. This HTML is saved to the .ipynb document. That ipynb could be loaded in another frontend; the file format is compatible between all of these tools. This means we don't know when creating the embed HTML necessarily which frontend we'll be rendered in. We could do environment detection at Observable cell load time with postMessages, but it would be nice to start with uniform CSS that works well with all frontends.

Our embed is not usable when a notebook is loaded without an internet connection. This is probably ok. It's conceivable that we could save all the assets from a notebook tarball into the .ipynb file, but embeds would stop autoupdating. I don't think we want this.

thomasballinger commented 4 years ago

Altair maintainer Jake just tweeted about these edge cases: https://twitter.com/jakevdp/status/1242928003992043520?s=21