starboard-notebook VS pyodide

This is really wonderful! The discussion about lay people's knowledge of sql reminded me that the Pandas API is often useful for non-sql folk. Likewise there are some projects similar to dirtylittlesql to bring Python data manipulation to the browser.

https://github.com/jtpio/jupyterlite

https://github.com/gzuidhof/starboard-notebook

You could consider an in browser notebook to get your cost down to near nothing - it depends a bit on what kind of tasks your students do whether they fit in the browser (one wouldn't train a large neural network in one for instance)

There's Starboard (which I'm building, it's built specifically for the browser and can integrate into a larger app deeply) and JupyterLite (the closest you will get to JupyterLab in the browser), either can be a good choice depending on your requirements. Both use Pyodide for the Python runtime.

[1]: https://github.com/gzuidhof/starboard-notebook, demo: https://starboard.gg

[2]: https://jupyterlite.readthedocs.io/en/latest/

A few examples of web-applications that have this problem are in-browser video converters using ffmpeg.wasm, a web-based notebook that supports Python and multithreaded Emscripten applications.

As someone building an in-browser notebook I have a lot of opinions on notebook environments. Notebooks serve different purposes, sometimes the notebook itself is the end-goal because the author is creating an interactive tutorial or explaining a complex concept with a bunch of visualizations. Observable is a fantastic tool for that, and the kind-of-Javascript reactive programming system it is built on is a great fit for that.

Outside of that use-case, I think notebooks are great for the first 20% of the effort that gets 80% of the work done. If it turns out one also needs to do the other 80% of the effort to get the last 20%, it is time to "graduate" away from a notebook. For instance if I am participating in a Kaggle machine learning competition I may train my first models in a Jupyter notebook for quick iteration on ideas, but when I settle onto a more rigid pipeline and infra, I will move to plain Python files that I can test and collaborate on.

This "graduation" from notebook to the "production/serious" environment should be straightforward, which means there shouldn't be too much magic in the notebook without me opting into it. Documentation in my eyes is not so different, I should be able to copy the examples easily into my JS project without knowing specifics of Observable and adapt it to my problem. Saying "don't be lazy and just learn Observable", or "you must learn D3 itself properly to be able to use it anyway" is not helpful. Observable being a closed, walled garden doesn't help: not being able to author notebooks without using their closed source editor is a liability that I can totally understand makes it a non-starter for some companies and individuals.

I think it's ok to plug my own project: It's called Starboard [1] and is truly open source [2]. It's built on different principles: it's hackable, extendable, embeddable, shareable, and easy to check into git (i.e. I try to take what makes the web so great and put that in a notebook environment). You write vanilla JS/ES/Python/HTML/CSS, but you can also import your own more advanced cell types. Here's an example which actually introduces an Observable cell type [3] which is built upon the Observable runtime (which is open source) and an unofficial compiler package [4]. I would be happy for the D3 examples to be expressed in these really-close-to-vanilla JS notebooks, but I can convince the maintainers to do so.

[1]: https://starboard.gg

[2]: https://github.com/gzuidhof/starboard-notebook

[3]: https://starboard.gg/gz/open-source-observablehq-nfwK2VA

[4]: https://github.com/asg017/unofficial-observablehq-compiler

If you want to play with Pyodide in a web notebook you can try Starboard [1][2].

A sibling comment introduces JupyterLite and Brython, which are Jupyer-but-in-the-browser, whereas with Starboard I'm trying to create what Jupyter would have been if it were designed for the browser first.

As it's all static and in-browser, you can embed a notebook (or multiple) in a blog post for instance to power interactive examples. The bundle size is a lot smaller than JupyerLite for the initial load - it's more geared towards fitting into existing websites than being a complete IDE like JupyerLab.

[1] https://github.com/gzuidhof/starboard-notebook

[2] https://starboard.gg

pyodide/packages

I tried building this with a Service Worker first and it didn't work, because Pyodide needs XMLHttpRequest.

I opened an issue about that here: https://github.com/pyodide/pyodide/issues/2432

https://github.com/pyodide/pyodide/pull/1882

But some other low hanging fruit include unvendoring the special encodings for Asian languages (hopefully everyone uses utf8), the decimal library, and the xml library which are all quite large and only occasionally used.

This uses Pyodide [0] under the hood [1], which is CPython compiled to WebAssembly. In all my tests of it, loading takes a long time ~5 seconds. Coldbrew [2], another distribution of CPython on Wasm, is another option with similar load times.

And Brython [3] is a completely different option without long load time: a Python interpreter implemented in JavaScript.

If load time is important, Brython is pretty nice. If feature completeness is important, Pyodide and Coldbrew are probably best.

[0] https://github.com/pyscript/pyscript/blob/main/pyscriptjs/sr...

[1] https://github.com/pyodide/pyodide

[2] https://github.com/plasticityai/coldbrew

[3] https://github.com/brython-dev/brython

Python via Pyodide

Those interested in this should check out Pyodide[0]. It basically "just works" so long as the libraries you import are pure Python or are part of the core scientific stack (the Pyodide authors have done the work to manually port all the C code behind numpy, scipy, etc.).

What I really wish for is for ~all Python packages to work in the browser without manual porting of the underlying C/Rust/etc. being needed, since a lot of the interesting and useful libraries aren't pure Python, and manual porting is non-trivial.

I'm not sure what the best route to that future is, but I'm guessing it'd probably help if Python had a wasm runtime in its standard library[1], since then authors of libraries that use C/Rust/etc. might make cross-platform builds (perhaps by default).

Regarding this Pycon speech, it seems that it's related to this entry in the 3.11 changelog[2], which the speaker was heavily involved with:

> CPython now has experimental support for cross compiling to WebAssembly platform wasm32-emscripten. The effort is inspired by previous work like Pyodide. (Contributed by Christian Heimes and Ethan Smith in bpo-40280[3])

[0] https://github.com/pyodide/pyodide

[1] https://discuss.python.org/t/add-a-webassembly-wasm-runtime/...

[2] https://docs.python.org/3.11/whatsnew/3.11.html

[3] https://bugs.python.org/issue40280

Wow this is amazing. Now all I need to deploy static machine learning demos in documentation is https://github.com/pyodide/pyodide/issues/2198

yes you can do that : https://github.com/pyodide/pyodide