Many improvements

[jtpio]

• Support both IFrame and Web Worker as backends (IFrame for better DOM support)
• Port some features from xeus-javascript
• Example notebooks

ReadTheDocs preview: https://jupyterlite-javascript-kernel--20.org.readthedocs.build/en/20/

[bollwyvl]

Lovely stuff to see! Takes me back to the bad old jyve days.

One nit, however: while simple, references to window.parent will still block the main UI thread: in the context of, say, downloading/parsing some hundreds of megabytes of model weights, this could be a pretty real disadavantage. Staying on the postMessage bus would keep the architecture mostly the same, and while more complex than reaching outside the box, might eventually allow for best-effort isolation on a separate domain (though it would require juggling origin).

Indeed, I think an upstream, visible IFrameKernel would be most excellent for many things: for example, pyodide and p5 could do all their crazy DOM things. And, on the isolation front, one could even double wrap an lFrameWorkerKernel, again still with the same wire protocol.

The biggest downside of iframe, of course, is that a ServiceWorker can't own one, so multi-tab-single-kernel stuff would still need a hub window.

[jtpio]

Yeah the IFrame is mostly so that the p5 kernel can be a thin layer on top of this javascript-kernel, and benefit from all the nice features.

Also because xeus-javascript currently uses a Web Worker. So there could be two offering:

• xeus-javascript : Web Worker
• jupyterlite-javascript-kernel: IFrame

Otherwise yes, maybe we could keep the postMessage interface, and even allow two backends for this kernel (IFrame or Web Worker).

For now this could already be shipped (maybe in a pre-release first) since it already brings many improvements.

Then we could also consider:

• @jupyterlite/javascript-kernel exposes all the nice stuff as reusable components and helpers, that xeus-javascript could simply reuse.
• Or move the common stuff (display, executor, ...) to a separate package. That package could be where JS widgets may be implemented at some point

[bollwyvl]

Right: end of the day, they're all javascript kernels, just some weigh more. I guess that might be an argument for moving this back into the main repo, even if it continues to be a standalone PyPI package.

[jtpio]

Gonna stop here for now. It's already a bit of a leap compared to the current feature set.

Will follow-up with a pre-release so it can be tested downstream more easily.