The article describes what is possible with Python in a browser, but misses an important detail: how much memory it consumes and how much CPU it uses.
Python is not a fast language. For example, consider a simple loop:
for i in range(10):
pass
In Python, this will be compiled into: a call to range(), heap allocation of an Iterable, calling getIterator() on an Iterable (which might also do allocation), calling next() on an Iterator while catching for StopIteration exception (and calls are often slow in interpreted languages). While in C we could just have a loop without any calls.
I remember how I had to use a Dart-based web application (compiled to JS) in one of Google's advertising products. The script weighed around several megabytes and everything was so slow. Furthermore, there also was a small and useless "what's new" applet, and it probably was shipped with a separate copy of Dart runtime because it weighed several megabytes too. Obviously this was a product intended to be used only on latest MacBooks, not on a Windows XP laptop.
It is totally fine to write such application for youself, or maybe for internal use, but if you are a corporation with millions of users, I think you should pay a little attention to performance and choose a better technology. Or, if you are of a Google scale, find a way to optimize the code.
The incumbent is not C, it is JavaScript. Initially JavaScript was also simply run on an interpreter. And it wasn't particularly fast until it got considerable attention by Google & Co, and browsers competing for "who can run this silly JavaScript benchmark the fastest".
Then complaining about how more abstract languages like Python are inefficient compared to C is not fair. These calls to range and Exception handlers are there on purpose, to help the developer avoid writing boilerplate code for the millionth time, and focusing on the problem itself, writing cool things.
C would be a terrible language for the Web I would argue. Web "development" was never a thing for the greybeards and "I dream in assembler"-types (not that I want to exclude anyone, I mean it didn't attract that crowd and another instead).
Any challenger for JavaScript must be approachable, easy to understand, easy to write and read. Easy to fix and modify (most "Web Apps" are already obsolete the moment they hit deployment).
Heck, why not go full x86 instructions? Hm, then there are millions of iPhones and Androids on the Web that are not x86... Write our own Assembler?! Let's call it WebAssembly!
I didn't write that you need to program your website in C. Obviously it is more convenient to use high-level languages. Everybody wants to write less code. I use Python myself, although not for work. But it would be a good idea to design high-level languages so that it would be easy to compile and optimize them.
For example, JS has no classes and uses prototype inheritance, and you can even change prototype at runtime. This is absolutely useless, inconvenient feature and it makes optimization (like JIT compilation) much more difficult (for example, before calling a method you must ensure that the prototype didn't change, the method was not replaced and so on).
In 95% (arbitrary number) of cases you just need classes with a fixed set of fields and methods known at compile time, which is very optimizer-friendly.
On the opposite: not only it isn't unfair, it's absolutely necessary. Over the years we witnessed the birth of so many languages, and each of them promised to be more safe than C while keeping performance "close to C". Now we have a cornucopia of programming languages, many of them are definitely "safer" than C (in the sense that it is more difficult or impossible to create some types of errors like buffer overflows), but in terms of performance there still seems to be a considerable gap. Having bad performance is bad for the users, bad for the environment (in terms of direct energy consumption and more power-hungry hardware needed), and bad for software companies (who are limited in what they can do).
I believe Hacker News’s backend is written on a Lisp (or, more precisely, Arc). In this context, JavaScript, Python and C are being debated for a role of client-side language handling DOM events.
Also, C and Lisp are different breeds. It’s wrong to put them in one bucket of “greybeard” languages. Some Lisps gained traction in the front end space (see ClojureScript).
Hacker News does have a bit of frontend, written in JavaScript. You can see some here https://news.ycombinator.com/hn.js, I'm unaware if it's everything or just a part.
You can transpile this to a more efficient systems language using py2many or another transpiler and all these problems go away if you're willing to sacrifice some of the dynamic features of the language and embrace static types.
The difference is just scale of commercial investment.
JS got fast because Google and friends started an arms race on it, since the adoption scale justified pouring resources into optimizing efforts.
Python has a large amount of developers' mindshare, which makes its use in the browser potentially worthwhile for large interests invested in the ecosystem (e.g. Anaconda). However, the problem is so big that the cost/benefit ratio for any given group that would want to tackle it, is still fundamentally unattractive. Python developers are legion, but still not a patch on JS users.
This is where WASM is a potential game-changer: by effectively dividing the problem in two and sharing the load for the first half with a lot of other ecosystems, the cost/benefit calculation improves significantly enough that commercial interests seem more willing to invest. CPython speeds, after the temporary v3 setback, get better and better every year; likewise WASM speeds. If their coupling becomes normal, enough effort will go into it that this consideration will just go away.
WASM won't change anything. Python is compiled into bytecode and slowly interpreted. Any optimizations at WASM level won't change the bytecode. For example, they won't turn range()-based loop into a loop with a counter.
Also, it is unlikely that compiling to WASM will be more effective than to native code because browser cannot afford spending as much time on optimization as a native compiler. Therefore WASM will always be slower than a native code.
If you want to benefit from amazing optimizations that were done for JS, then it is better to transpile your Python code directly into JS.
> Any optimizations at WASM level won't change the bytecode.
No, but the bytecode gets better and more efficient with new releases. The point at which it becomes acceptable depends on the use case, of course.
> it is unlikely that compiling to WASM will be more effective than to native code
It doesn't have to be more effective, it only has to reach a point where the penalty is worth paying. After all, JS is slower than C, but you accept that as a part of larger trade-offs on manpower, ease of deployment, etc. Once the trade-off becomes acceptable for the use case, absolute benchmarks stop being relevant.
> If you want to benefit from amazing optimizations that were done for JS, then it is better to transpile your Python code directly into JS.
Why stop there? At that point you might as well use JS, since you get the best speeds and chances are you'll have to deal with it anyway at some point. There are already solutions like that out there, and they are not popular precisely for that reason. The beauty of using WASM is that you'll probably never have to touch JS.
> Also, it is unlikely that compiling to WASM will be more effective than to native code because browser cannot afford spending as much time on optimization as a native compiler.
No reason whatever compiles the code to wasm can’t perform all the expensive optimizations and the wasm execution environment just runs it.
In fact, I would be very disappointed in a tool that didn’t run optimization passes over the code while it still had the language specific information to inform the optimizer.
Then you just pass the multi-megabyte wasm payload over to the browser to render your static content — all’s still good in the webdev world.
How long have there been any serious official investments to make Python faster though? Python just recently touched interpreter level optimization from 3.10 and AFAIK they haven't begun JIT works yet. I'm not saying that Python will ever become as fast as JS, but neither JS was not designed to be fast; it was V8 that made it fast.
Python (and JS) is not optimizer-friendly and it is very difficult to write a JIT for it (you can read a description of JIT in WebKit dev blog to get an idea what it takes to write it).
Not "official" as in "officially sponsored by PSF" but the PSF is undersupported and doesn't have extra resources for something like that. There are many longstanding projects that attempt to make Python faster by reimplementing it (or parts of it), and CPython itself has become incrementally substantially more efficient over the last few releases.
Ironically Dart was built for the web [1] (as a Dart VM for Chrome, then later on compiled to JS). One would expect something like that to do well on the web.
But if your loop is busy doing stuff that’s hundreds of bytecode ops long, is worrying about the few extra bytecode ops that a for loop takes worth it?
How else would they feel superior to someone else, if not by comparing Python/JS to C's speed all the while talking about applications where C is never going to be used?
Indeed, taken to the extreme a Pyodide-based jupyter is available[1] which uses the same underpinnings as pyscript. It might not be perfectly efficient but it's totally usable, especially considering it moves the compute from a server to the client.
At this point the main issue I've seen is the slow load time (not a problem for jupyterlite but is for pyscript). Hopefully this can improve with time and regardless I think there are a lot of cases for pyscript to remove the need for server-side code and the associated maintaince.
We added support for PyScript using Collagraph, which allows you to define single file components with a Vue-like syntax.
Excerpt from the project README:
Write your Python interfaces in a declarative manner with plain render functions, component classes or even single-file components using Vue-like syntax, but with Python!
- Reactivity (made possible by leveraging observ)
- Function components
- Class components with local state and life-cycle methods/hooks
-Single-file components with Vue-like syntax (.cgx files)
- Custom renderers (PySide, pygfx and now PyScript)
Developer time is still more expensive than 'runtime'
Talking about optimizing a range(10) loop was valid in the 90's, not today
Yes, CPython could be better, but there's Pypy. And still, CPython runs circles around the optimized Dart example you gave.
"pay a little attention to performance" cool, are we going to take all the crap out of JS that makes it inefficient?
"pay a little attention to performance" sounds to me like you're a fan of those C compilers that break code on purpose because the developer forgot some arcane detail. To what I call BS
Obviously, one loop in Python won't hurt performance. But reality is that people will try to build SPA on this technology. They will port Redux, that uses immutable objects and recreates whole graph of objects on every event. They will try to move SQLAlchemy and Django into the browser. Isn't it cool (for inexperienced developer), you just import a script from CDN and can write Django code? And this will run on a 10-megabytes interpreter in WASM.
Of course if you are writing an internal app and can provide M2 MacBook to every employee, then it is totally fine. But if you are writing applications for wide audience, it is a different thing.
I remember that one of early users of Vkontakte (a Russian clone of Facebook) was impressed that the site was loading fast on his old computer. As I remember, its JS code was written in vanilla JS without libraries like jQuery. Today the hardware is better, but if you will run SQLAlchemy in a browser to save development cost, your site's loading time won't impress users.
There is absolutely no requirement or indication that Python UI framework will have to follow the same principles as JS ones.
> your site's loading time won't impress users.
Anybody who used client-server apps in the 80s and 90s is not impressed by browser-based apps either. Those expectations can be managed in so many ways.
> They will try to move SQLAlchemy and Django into the browser.
Yes that will be a complete non starter!
I'm all for fighting inefficiencies and slow code, but fixing things like this, or Redux etc go much further than a simple for i in range() loop in Python
True, but there are limits. It’s surprising how many apps and webpages I use that are just straight up slow - things that should load instantly instead take a second or two. The web is a good application for this to some extent since there are other latencies that make this less noticeable, but they still exist.
Anything written to be performant is immediately noticeable - things just happen when you click a button. Dev time > runtime, but I’d argue some runtimes are so slow they begin to eat into user time too.
I notice this too. If I open a SPA there almost always will be a spinning circle and I have to wait like 3 or more seconds before I can see the content. In theory one can write a SPA that would load instantly, but in reality it will be a spinning circle.
I can only imagine how many people will just close the tab and move to next search result.
Python is not a fast language. For example, consider a simple loop:
In Python, this will be compiled into: a call to range(), heap allocation of an Iterable, calling getIterator() on an Iterable (which might also do allocation), calling next() on an Iterator while catching for StopIteration exception (and calls are often slow in interpreted languages). While in C we could just have a loop without any calls.I remember how I had to use a Dart-based web application (compiled to JS) in one of Google's advertising products. The script weighed around several megabytes and everything was so slow. Furthermore, there also was a small and useless "what's new" applet, and it probably was shipped with a separate copy of Dart runtime because it weighed several megabytes too. Obviously this was a product intended to be used only on latest MacBooks, not on a Windows XP laptop.
It is totally fine to write such application for youself, or maybe for internal use, but if you are a corporation with millions of users, I think you should pay a little attention to performance and choose a better technology. Or, if you are of a Google scale, find a way to optimize the code.