pyodide VS pyscript

Pyodide has numpy, scipy, matplotlib, pandas, and as of last month, even polars. https://github.com/pyodide/pyodide/pull/5282

Pyodide is far from a perfect CPython and even the packages it includes often have limitations you won't find when running natively. But there's definitely enough here to be interesting and even somewhat useful. Here's an interactive app written on Pyodide that uses astropy, numpy, and matplotlib: https://shinylive.io/py/examples/#orbit-simulation

We evaluated the pyodide ecosystem for louie.ai last year and too much didn't work, eg, we couldn't get data in for arrow or parquet, which are table stakes for python data work

My guess was 2025 would be more practical for these libs ... And behold: https://github.com/pyodide/pyodide/issues/2933

Very cool to see!

Compiling Fortran to WebAssembly is still an area of active development (see 1, 2, 3, 4, and 5). At the time of this post, a common approach is to use f2c to compile Fortran to C and then to perform a separate compilation step to convert C to WebAssembly. However, this approach is problematic as f2c only fully supports Fortran 77, and the generated code requires extensive patching. Work is underway to develop an LLVM-based Fortran compiler, but gaps and complex toolchains remain.

Very cool! Kind of seems like a relic at this point though, cool for studying but probably better to use Pyodide [1] in practice? This is what powers JupyterLite [2], which is a fully fledged Jupyter IDE with support for packages, in browser.

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

2: https://github.com/jupyterlite/jupyterlite

We implemented an in-browser Python editor/interpreter built on Pyodide over at Comet (our users are data scientists who need to build custom visualizations quite often, and the most familiar language for most of them is Python).

One of the issues you'll run into is that Pyodide only works by default with packages that have pure Python wheels available. The team has developed support for some libraries with C dependencies (like scikit-learn, I believe), but frameworks like PyTorch are particularly thorny (see this issue: https://github.com/pyodide/pyodide/issues/1625 )

We ended up rolling out a new version of our Python visualizations that runs off-browser, in order to support enough libraries/get the performance we need: https://www.comet.com/docs/v2/guides/comet-ui/experiment-man...

Thank you! Yes, one of the items in the Roadmap is support for Pyodide (https://github.com/pyodide/pyodide) for running in-browser python on the results of each of the code blocks! This should allow most ML libs to be usable in-browser! This is pretty high-up on our priority list.

If I understand correctly, WASM only makes sense for compiled languages, you can run the python interpreter in WASM of course[1], but that will be at a significant performance disadvantage to the native javascript interpreter, and it's also something that has to be loaded every time you load the website.

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

If you absolutely need something comparable to Sympy, then one option might be to figure out how to best call Sympy from Rust. e.g. - RustPython, although it seems like Sympy isn't supported yet - Pyodide, and figuring out how to run it outside of a web browser. Probably also not very easy. - PyPy, and having a pretty simple Python binary for every platform - ...

For running programming languages other than JavaScript in the browser there is Emscripten and WebAssembly. There is v86, where a Linux build is compiled to WASM. Folks have written QuickJS into a Linux build compiled to WASM, Node.js into the Linux buildroot https://github.com/cemalgnlts/now, so Python or CPython can be written to the image and loaded into the browser as WASM as well https://github.com/pyodide/pyodide.

PyScript is an open-source framework that allows you run your Python code in the browser. With PyScript, developers can write Python scripts that directly interacts with the browser, just like JavaScript does.

Where to check it out: https://github.com/pyscript/pyscript

You are right for the most part. I attended a talk about pyscript[1] (runs python in the browser using wasm which is similar) and there is a 2x performance hit.

[1] https://pyscript.net

PyScript maintainer here - I'd love to hear more about this application! Either here, or over on our Discord (invite link is on the GitHub Page [1]).

[1] https://github.com/pyscript/pyscript?tab=readme-ov-file#summ...

For the first question - why your code previously created an HTML node but now just prints out the literal characters of the HTML - that was a change made in 2022.12.1, in Pull Request 915 to be specific. You can check out the single-line change that caused this, if you want. Essentially, calls to Element.write() or display() have their contents escaped by default, which wasn't the case before.

Note that in the current release (2023.03.1 at time of writing), py-[event] listeners are only hooked up once at page-load time, so changing that attribute after the page loads won't do anything. In the upcoming release, py-[event] handlers are dynamically attached and managed each time a py-[event] attribute on the page is changed. (PR 1435)

PyScript started as a usability layer around Pyodide for those not used to working in JS. It's now working on things like incorporating the Micropython runtime as an alternative, moving the interpreter to a worker thread, adding a plugins ecosystem, easier events API's, and more.