Handling javascript dependences for rendering outputs

[nthiery]

This is a tentative summary of a discussion over lunch with @jasongrout.

@Jasongroup: please review, as I am still a novice on the Jupyter architecture.

Rendering rich outputs often requires the browser to load additional javascript libraries (e.g. threejs, mathjax, jupyter widgets ...). Therefore, one of the agents must be responsible for maintaining the list of ditto javascript libraries according to the kind of outputs the kernel may produce. Here are potential options and their advantages and drawbacks.

The static web page using ThebeLab:

• Pros: no need to implement anything; usually the page authors knows the kind of output that will appear.
• Cons:
  • Adds a rather technical burden on page authors.
  • If a user tweak the inputs and goes beyond the original scope, some outputs may not be rendered.
  • As kernel evolve, the required javascript libraries may change, and the page go out of sync.

ThebeLab:

• Cons: There are too many use cases out there, and ThebeLab could not reasonably bundle all javascript libraries that could be used for the outputs of all kernels

The Jupyter server providing the kernels:

• Requires: design a protocol for ThebeLab to request the javascript libraries from the Jupyter server; basically mimicking what's done for the notebook; question: shall Jupyter server serve directly the libraries? or just the list of required libraries?
• Pros: That's the usual approach: the server maintainer (usually through packagers) is responsible for maintaining in sync the installed kernel and javascript extensions.
• Cons:
  • If this protocol requires a change in Jupyter, then it may take a long time before it's adopted by most of the current Jupyter deployements used by ThebeLab.
  • At some point we may want to have lightweight kernel providers that need not run a full Jupyter instance.

The kernels:

• Requires: a protocol for the kernels to provide metadata specifying (possibly lazily) which js libraries are needed, and for ThebeLab or the Jupyter server to resolve where to fetch them.
• Pros:
  • that's a natural location: the kernel authors know best the kind of output that may be produced and what libraries may be needed. But this may require the kernel to know more about the interface (web/qt/...) than it may want to.
  • could be generally useful to simplify the Jupyter server management
  • if done lazily, this could save the browser from loading a bunch of js libraries that actually won't get used.