I haven’t wrapped my head about the Jupyter architecture, but it seems feasible to have a pure JavaScript kernel. Has there been any initiative or planning to do this? If not, how come?
I’ve found widgetti/ipyreact, but this doesn’t succeed in removing Python from the workflow.
I can imagine a few use cases for this. It might be useful for learning or teaching JavaScript/TypeScript, or it could be used to add the rich library of web components to notebooks. This could also remove the need to Python wrappers around JavaScript code. For example I’m currently using ipyleaflet in my notebook in order to get an interactive map, but using Leaflet directly, without Python, would be simpler and better remain in sync with upstream Leaflet.
Technically I guess the kernel backend could be a separate node process, or it could be the browser’s own JavaScript engine in a similar way to Pyodide running in the browser.
As I understand, React is already used in the frontend of ipykernel, does this make everything easier?
That’s part of the fun part, is folk agreeing on what exactly that is. The definition I like, which coincides with this use case, is “the JS supported by browsers,” with all its warts, specifically, “the one currently supported by Firefox LTS,”
Anything node/deno/bun/quickjs wouldn’t be any closer to import "leaflet" and actually being able to do proper slippy maps in the DOM… unless it re-invented everything that widgets do by separating compute and display.
the browser’s own JavaScript engine
Presently, the two JupyterLite javascriptkernels run in WebWorkers. While still possible, this reduces the chance of fully bricking your editor experience because of a runaway while loop, but means they don’t have access to the same DOM as a leaflet instance. Some work is underway to offer an iframe-based kernel which would be; not sure about the xeus one.
React is already used in the frontend
react is indeed involved (and difficult to avoid) in the @jupyterlab/ui-components-based clients such as JupyterLite, Notebook 7+ and JupyterLab itself, but the relationship has never been all that smooth… but the “react is life” thing was tried on the nteract stack, and never really caught on.
Thanks, so there are some existing kernels, but they’re not able to actually render elements because they can’t access the DOM. I guess I’m happy to take the risk of the code breaking my browser because I’m the author, and because the exported notebook that I share with my end user is frozen and won’t be running the code on their machine. For now I’ll probably wait to see what happens with jupyterlite/javascript-kernel, because iframe rendering sounds promising.