3 ms·

While I love the tech behind this (as well as the good article and fun demo video), I'm very skeptical that this will be a good approach for most web apps. I ho

While I love the tech behind this (as well as the good article and fun demo video), I'm very skeptical that this will be a good approach for most web apps. I hope it doesn't turn into Python programmers suddenly pulling in 7MB of WASM code/data just to render their websites (along with a 5s startup time), adding yet another layer of complexity and virtualization between their code and the browser. I think the interest in the tool is overall a good thing, but I think we need to be very careful about what kinds of projects we use this for.

sassy_quat 4y ago
Did Microsoft psyop Python into promoting the shipping of terrible web apps through Universal Windows Platform? Still waiting for Windows Platform to become Universal.
chenzhekl 4y ago
I agree that the bundle size is a big concern. Another aspect that I am worried about is Python’s performance. JavaScript is not a fast language, and Python is an order of magnitude slower. What makes Python shine today rely on packages with native code. I don’t know how many of them can be run flawlessly in the browser without modification.
- mr_toad 4y ago
  A lot of the work porting these libs to wasm has already been done. But you can’t expect every Python program to just run.
epistasis 4y ago
Don't forget the 30 CPU minutes to solve the conda/mamba package requirements for the web app's dependencies.
coder543 4y ago
I agree with everything you said there. I will also point out that there is some fairly low hanging fruit in this PyScript project, if they will attempt to be more "web native". Take this example: https://pyscript.net/examples/panel_kmeans.html https://pyscript.net/examples/panel_kmeans.html It loads a bunch of large `.whl` files, and they're served up without any apparent compression, which raised my eyebrows immediately. Upon closer inspection, this is a zip file under the hood, so they probably figured that compressing a zip file over the wire was a waste of resources, and they're not really wrong... but, does it need to be a zip file? That means they're shipping a library to handle decompressing and manipulating zip files. If we unpack the zip file and make an uncompressed tarball out of it, we can feed that through brotli and get a much smaller file: 18M bokeh.whl 9M bokeh.tar.br The network transfer is now twice as fast, and the browser will do a phenomenal job at decompressing this resource before handing it to the application. The browser will (presumably?) decompress these resources in parallel instead of the (likely) sequential process currently being used, the browser should be faster at decompression anyways, and not handling decompression means less code that PyScript has to ship. Even better, subsequent page loads wouldn't have to keep decompressing the same bundle over and over... it'll just be a cached resource. You'd still need to handle the tar format, but that shouldn't be too terrible. Basically all browsers support Brotli[0], and you could always have a slow fallback for the... checks notes... IE 11 users out there. This kind of low hanging fruit won't magically fix all the problems with PyScript, but it could go some distance towards making it more palatable for the purpose of bundling up a lightly modified Python application for use over the web. [0]: https://caniuse.com/brotli https://caniuse.com/brotli
toyg 4y ago
The virtualization that WASM does is actually cleaner than what other similar attempts do. In a field where implementations typically end up being a thin veneer over JS objects (which means you typically end up having to get your hands dirty and work with JS bits here and there), WASM should clear the slate clean enough for most uses, so if you write Python and target WASM, you'll not have to write a single line in JS (well, maybe a standard cookie-cutter loader while the thing downloads the first time, but that's it).

sassy_quat 4y ago

Did Microsoft psyop Python into promoting the shipping of terrible web apps through Universal Windows Platform? Still waiting for Windows Platform to become Universal.

chenzhekl 4y ago

I agree that the bundle size is a big concern. Another aspect that I am worried about is Python’s performance. JavaScript is not a fast language, and Python is an order of magnitude slower. What makes Python shine today rely on packages with native code. I don’t know how many of them can be run flawlessly in the browser without modification.

mr_toad 4y ago
A lot of the work porting these libs to wasm has already been done. But you can’t expect every Python program to just run.

epistasis 4y ago

Don't forget the 30 CPU minutes to solve the conda/mamba package requirements for the web app's dependencies.

coder543 4y ago

I agree with everything you said there. I will also point out that there is some fairly low hanging fruit in this PyScript project, if they will attempt to be more "web native". Take this example: https://pyscript.net/examples/panel_kmeans.html https://pyscript.net/examples/panel_kmeans.html It loads a bunch of large `.whl` files, and they're served up without any apparent compression, which raised my eyebrows immediately. Upon closer inspection, this is a zip file under the hood, so they probably figured that compressing a zip file over the wire was a waste of resources, and they're not really wrong... but, does it need to be a zip file? That means they're shipping a library to handle decompressing and manipulating zip files. If we unpack the zip file and make an uncompressed tarball out of it, we can feed that through brotli and get a much smaller file: 18M bokeh.whl 9M bokeh.tar.br The network transfer is now twice as fast, and the browser will do a phenomenal job at decompressing this resource before handing it to the application. The browser will (presumably?) decompress these resources in parallel instead of the (likely) sequential process currently being used, the browser should be faster at decompression anyways, and not handling decompression means less code that PyScript has to ship. Even better, subsequent page loads wouldn't have to keep decompressing the same bundle over and over... it'll just be a cached resource. You'd still need to handle the tar format, but that shouldn't be too terrible. Basically all browsers support Brotli[0], and you could always have a slow fallback for the... checks notes... IE 11 users out there. This kind of low hanging fruit won't magically fix all the problems with PyScript, but it could go some distance towards making it more palatable for the purpose of bundling up a lightly modified Python application for use over the web. [0]: https://caniuse.com/brotli https://caniuse.com/brotli

toyg 4y ago

The virtualization that WASM does is actually cleaner than what other similar attempts do. In a field where implementations typically end up being a thin veneer over JS objects (which means you typically end up having to get your hands dirty and work with JS bits here and there), WASM should clear the slate clean enough for most uses, so if you write Python and target WASM, you'll not have to write a single line in JS (well, maybe a standard cookie-cutter loader while the thing downloads the first time, but that's it).