
The Python scientific stack, compiled to WebAssembly - tosh
https://github.com/iodide-project/pyodide
======
mr_toad
Part of an effort to make a Jupytr notebook-like environment without relying
on server side code.

[https://github.com/iodide-project/iodide](https://github.com/iodide-
project/iodide)

~~~
xtrapolate
> "Part of an effort to make a Jupytr notebook-like environment without
> relying on server side code."

So there won't be any server side code, you'd just be downloading the entire
Python stack and dependencies every time you want to use this through your
browser. This time it will be WASM though, instead of x86/x64/pyc.

That we can, doesn't mean that we should.

~~~
m_mueller
I guess we need an in-browser package management like npm?

~~~
adrianN
Just compile Debian to WASM and use apt.

~~~
lx3459683
Just run a browser in your WASM Debian to hit the same page.

------
lx3459683
I benchmarked this recently. It comes in at 4-10x slower than cpython for
random typical use cases on my machine, which is not too shabby at all. The
author also states that numpy is slower than it should be due to lack of
support for BLAS at this time.

The real impressive feat to me isn't hosting jupyter in the browser. It's
access to a reasonably fast implementation of numpy in the browser which
smokes native JS code for homogeneous array operations. I would love to see a
minimalistic WASM implementation of numpy that can seamlessly interop with
normal JS. Such a library would open up all sorts of possibilities that aren't
currently feasible due to perf reasons.

~~~
singularity2001
Interesting, how do you derive at "4-10x slower"?

Running the exported notebook here takes

time py3 python.py real 0m0.145s

chrome: load html: 2sec run html: 13sec!

That's not 10 times slower, but a 100 times slower!

Still good start.

~~~
lootsauce
I have used Weblas "GPU Powered BLAS for Browsers" for matrix multiply and it
smokes!
[https://github.com/waylonflinn/weblas](https://github.com/waylonflinn/weblas)

------
alexeiz
This is great. Many times I wanted to showcase to colleagues who don't use
Python how things would work in Python, but they don't have either Python or
Jupyter installed. So I had to run Jupyter server in my own environment and
give them access to it. This is quite an inconvenience as well as a security
risk. Having a completely server-less Python/Jupyter environment should make
this kind of showcasing much easier.

~~~
nsriv
You could also use a Jupyter notebook uploaded to colab.research.google.com

~~~
existencebox
I'll chime in to mention notebooks.azure.com as well.

(Typical disclaimer, I'm a dev on the azure notebooks team; we just try to
solve exactly the scenario GP was asking so I would be remiss to not throw our
hat in the ring)

------
krona
_Coming soon [...] Plotting using D3 from Python_

Wouldn't Bokeh make more sense? I'd be very interested in a serverless Bokeh
that didn't force me to ditch Python, for example.

~~~
mdboom
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...](https://iodide.io/pyodide-demo/matplotlib-
sideload.html?sideload=https://matplotlib.org/examples/animation/rain.py)

------
nerdponx
What happens to all of the C code in Numpy, and the calls to external
libraries like BLAS?

~~~
Scarblac
In particular, does this mean Javascript has access to Numpy? Sounds
unbelievable, but would be extremely cool.

~~~
mdboom
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.

------
acbart
I do a lot of work with Skulpt, which included adding (somewhat superficial)
support for MatPlotLib. You can make line plots, scatter plots, and
histograms. It's a pretty cool system, though I will say developing in it
isn't always very fun :)

------
sitkack
The goal of [http://www.graalvm.org/docs/why-graal/#for-ruby-r-or-
python](http://www.graalvm.org/docs/why-graal/#for-ruby-r-or-python) is to run
scipy.

------
amelius
Is there a performance hit compared to "native" Python?

~~~
lkbm
There's a chart and some discussion here:
[http://droettboom.com/blog/2018/04/04/python-in-the-
browser/](http://droettboom.com/blog/2018/04/04/python-in-the-browser/) (and
some followup at [http://droettboom.com/blog/2018/04/11/profiling-
webassembly/](http://droettboom.com/blog/2018/04/11/profiling-webassembly/) )

TL;DR: pyodide in Firefox was slower than cpython.

~~~
amelius
Thanks. Note that the author of that post said:

> UPDATE 2018-04-11: My hunch was wrong, and I was able to get to the bottom
> of the root cause and significantly speed up these benchmarks.

And there's an updated graph here:

[http://droettboom.com/blog/2018/04/11/profiling-
webassembly/](http://droettboom.com/blog/2018/04/11/profiling-webassembly/)

------
X6S1x6Okd1st
Huh I am getting

``` TypeError: window[s] is undefined ```

with firefox.

~~~
mdboom
File a bug over at [https://github.com/iodide-
project/pyodide/](https://github.com/iodide-project/pyodide/)

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

