mdboom

These are some good points.

One small way in which Iodide advances this is that by having the editor being a single text editing widget (rather than multiple cells as you see in Jupyter and others), it should be easier to replace that widget with an alternative editor, or (using an extension) link to a native editor on the machine.

But all of these other issues, I agree, are things that would be nice to improve upon. I think in part this comes from so much of the "productivity on the web" stack is dominated by big players (Google Docs, Microsoft Office 365) there hasn't been a big push for interoperability and customizability. I'd love to see a movement around that (but definitely out-of-scope for what the Pyodide team can currently take on!)

Cython works for ahead-of-time compilation. (Pandas requires it, for example). Making it work in the browser would also mean putting a C compiler there, which people have done. I have no idea how well that would all hold together, though.

Actually, Numpy-using-code is closer to native speeds than pure Python is.

The thing that seems to cause a greater gap between wasm and native speeds is lots of Python-level function calls, not the tight C loops that make up much of Numpy.

Bokeh could probably be done, but most of Bokeh's client/server complexity becomes unnecessary in this execution model.

More recently, pyodide has grown full matplotlib support. See, for example, https://iodide.io/pyodide-demo/matplotlib-sideload.html?side...

Yes. It uses the C implementations of BLAS and LAPACK that ship in the Numpy source tree.

Yep. You can "import" python objects over to the Javascript side and start using them from there. It's not as pleasant as working with Numpy in Python, of course, due to lack of operator overloading, of course.

File a bug over at https://github.com/iodide-project/pyodide/

I'd love to get to the bottom of that.

The plan is to build something based on conda.