The Python scientific stack, compiled to WebAssembly
1–10 of 54 posts
Re: The Python scientific stack, compiled to WebAssembly
#2Part of an effort to make a Jupytr notebook-like environment without relying on server side code.
Re: The Python scientific stack, compiled to WebAssembly
#3Coming 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.
Re: The Python scientific stack, compiled to WebAssembly
#4Part 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.
Re: The Python scientific stack, compiled to WebAssembly
#5Part 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 guess we need an in-browser package management like npm?
Re: The Python scientific stack, compiled to WebAssembly
#6Part 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.
That would be dumb, so why assume that would happen? You don’t download every picture on every refresh.
Re: The Python scientific stack, compiled to WebAssembly
#7Earlier 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?
Just compile Debian to WASM and use apt.
Re: The Python scientific stack, compiled to WebAssembly
#8Earlier 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?
In-browser package management, combined with caching of common dependencies, yes.
Like npm? No.
Re: The Python scientific stack, compiled to WebAssembly
#9Is there a performance hit compared to "native" Python?
Re: The Python scientific stack, compiled to WebAssembly
#10Earlier quoted context omitted.
I guess we need an in-browser package management like npm?
In-browser package management, combined with caching of common dependencies, yes. Like npm? No.
Well I'm not really into JS web development, but NPM and a bunch of Node-like extensions would give you compatibility with lots of existing libraries.