You're replacing one interpreted language for another.
Yes, Python is among the slower interpreted languages out there, but still. The debate between fast execution and programmer productivity is not a new one. Given Python's popularity, I'd say it's settled.
Yes, they link to examples and all of them run way slower than the equivalent JS version. Most likely because python has to ship its interpreter in the WASM bundle.
If the user experience is significantly worse, I don't care if it was easier for you to write the code.
Runtime and download time are two different things.
Pyodide runs at least ~10MB. That's a lot for a web app to handle, for sure. The use case there is most likely either scientific computing/data science (where JavaScript is just an obvious non-starter), or it's line of business somewhere where someone downloads an ERP app and just runs it. Those are already huge, as anyone who uses the stuff from ERP companies can attest.
No one is seriously proposing that you should use Pyodide, with the whole Python standard library, to add interactivity to a regular newspaper website or something like that.
MicroPython might be a good fit for that though. It's ~100k -- smaller than a lot of JS tooling.
But usually when we say "fast language" or "slow language," we're talking execution speed, not runtime size.
I agree with the sentiment but the purpose of WebAssembly is to be a compiler target for other languages, so we're not stuck with Javascript until the end of time, right? Will this always necessarily be substantially slower than Javascript?
> Will this always necessarily be substantially slower than Javascript?
Yes, interpreted Python will always be slower than JIT-compiled JavaScript.
PyPy.js [0] is a JIT compiler for Python that runs in the browser - its performance could be similar to JS but its development is currently “sleeping”.
We must think of the lessons of docker, the lessons of conda. Why, what with the web environments, so many, is there not a way to unify an environment? Of course! A virtual environment of python, on a virtual environment of the docker machine, on a virtual web browser, and there can be JIT throughout to make it only painfully slow and not excruciatingly slow! Abstraction is a Good Thing (TM) and the more abstraction, the better. There really ought to be an object oriented abstraction layer factory generator factory using Java OOP best practices, also a good thing (TM). If all goes well we may even be able to reach abstraction tier 17, which is two more layers of abstraction than the industry standard 15.
