Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Python scientific stack, compiled to WebAssembly

github.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: The Python scientific stack, compiled to WebAssembly

#21

Post by andybak »

xtrapolate wrote: post #4
mr_toad wrote: post #2

Part of an effort to make a Jupytr notebook-like environment without relying on server side code. https://github.com/iodide-project/iodide

> "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.

I can think of several scenarios where this could be useful.

Re: The Python scientific stack, compiled to WebAssembly

#22

Post by sp332 »

xtrapolate wrote: post #4
mr_toad wrote: post #2

Part of an effort to make a Jupytr notebook-like environment without relying on server side code. https://github.com/iodide-project/iodide

> "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.

There's an advantage even if you're running it locally. Now you can just load up some static HTML + JS files in your browser instead of spinning up a server and then pointing your browser at localhost.

Re: The Python scientific stack, compiled to WebAssembly

#23

Post by nsriv »

alexeiz wrote: post #19

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.

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

Re: The Python scientific stack, compiled to WebAssembly

#24

Post by Waterluvian »

xtrapolate wrote: post #4
mr_toad wrote: post #2

Part of an effort to make a Jupytr notebook-like environment without relying on server side code. https://github.com/iodide-project/iodide

> "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.

As long as it's framed properly it can be acceptable. Ie. You get to a page with details and a "load environment" button with progress bars and all.

Of course when it's like 50-100MB you wouldn't use it in some cases. But once cached you're golden for your repeat visitor audience.

Re: The Python scientific stack, compiled to WebAssembly

#25

Post by gh02t »

mjs2600 wrote: post #16
nerdponx wrote: post #11

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

C can compile to WASM, but I have no clue about external tools like BLAS. I'd assume that things like Numpy are able to work without tools like BLAS, but you might also be able to compile the essential ones to WASM as well.

NumPy can work without libraries like BLAS or LAPACK, but it will be sloooooooooow. There are C versions of those libraries however, maybe they are using those?

Re: The Python scientific stack, compiled to WebAssembly

#26

Post by nostalgeek »

m_mueller wrote: post #5
xtrapolate wrote: post #4

Earlier quoted context omitted.

> "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.

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

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

It exists and it's called bower.

Re: The Python scientific stack, compiled to WebAssembly

#27

Post by azakai »

nerdponx wrote: post #11

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

Python C extensions like NumPy are compiled into shared libraries, and loaded using dlopen() etc. normally by the main compiled Python runtime. (The only special thing here is that all those components are compiled to WebAssembly so it can run on the Web.)

Re: The Python scientific stack, compiled to WebAssembly

#28

Post by applecrazy »

Vinnl wrote: post #20
xtrapolate wrote: post #4

Earlier quoted context omitted.

> "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.

Well, you'd download the entire stack indeed - but not every time. Your browser does caching too.

Plus, if it’s packaged as a PWA, it can run offline and seamlessly update the runtime in the background using a Web Worker.

Re: The Python scientific stack, compiled to WebAssembly

#30

Post by orbital-decay »

Vinnl wrote: post #20
xtrapolate wrote: post #4

Earlier quoted context omitted.

> "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.

Well, you'd download the entire stack indeed - but not every time. Your browser does caching too.

It doesn't share the cache between the sites though. A local installation has only one runtime.
Post reply on HN