5 ms·

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 i

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.

your_challenger 4y ago
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. [1] https://en.wikipedia.org/wiki/Dart_(programming_language)#History https://en.wikipedia.org/wiki/Dart_(programming_language)#Hi...
- endtime 4y ago
  Flutter web is a thing now; not sure how popular it is, but Flutter in general is doing pretty well.
beebmam 4y ago
In C, this loop would get unrolled to a no-op in a release environment. Source: https://godbolt.org/z/1sb5Tb3xv https://godbolt.org/z/1sb5Tb3xv
- codedokode 4y ago
  I used an empty loop just to simplify an example. Obviousy in real code the loop would do domething useful and wouldn't be optimized out.
  - colejohnson66 4y ago
    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?
    - the-smug-one 4y ago
      It's not like those hundreds of bytecode ops aren't slow as molasses too, for similar reasons.
    - joaommartins 4y ago
      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?
d0mine 4y ago
As I understand, C extensions are used for CPU heavy work e.g., numpy is likely ported to WebAssembly.
- tempay 4y ago
  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. [1] https://jupyterlite.readthedocs.io/en/latest/ https://jupyterlite.readthedocs.io/en/latest/
- codedokode 4y ago
  No. People won't write C extensions. They will write something heavy like Redux (which recreates full object graph on every event) in Python.
  - ivoflipse 4y ago
    You'll like what we've done during my Hackathon https://github.com/fork-tongue/collagraph/pull/66 https://github.com/fork-tongue/collagraph/pull/66 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)
summerlight 4y ago
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.
- nerdponx 4y ago
  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.
- codedokode 4y ago
  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).
bipson 4y ago
I think comparing it to C isn't fair. 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! Oh, wait.
- danuker 4y ago
  > Web "development" was never a thing for the greybeards Hacker News is written in some Lisp, and I spend more time here than on any bloated SPA. Reddit with the old UI is a close second.
  - sevazhidkov 4y ago
    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).
    - Zababa 4y ago
      Hacker News does have a bit of frontend, written in JavaScript. You can see some here https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js, I'm unaware if it's everything or just a part.
raverbashing 4y ago
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
- Panzer04 4y ago
  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.
  - codedokode 4y ago
    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.
- codedokode 4y ago
  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.
toyg 4y ago
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.
- codedokode 4y ago
  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.
  - toyg 4y ago
    > 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.

your_challenger 4y ago

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. [1] https://en.wikipedia.org/wiki/Dart_(programming_language)#History https://en.wikipedia.org/wiki/Dart_(programming_language)#Hi...

endtime 4y ago
Flutter web is a thing now; not sure how popular it is, but Flutter in general is doing pretty well.

beebmam 4y ago

In C, this loop would get unrolled to a no-op in a release environment. Source: https://godbolt.org/z/1sb5Tb3xv https://godbolt.org/z/1sb5Tb3xv

codedokode 4y ago
I used an empty loop just to simplify an example. Obviousy in real code the loop would do domething useful and wouldn't be optimized out.
- colejohnson66 4y ago
  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?
  - the-smug-one 4y ago
    It's not like those hundreds of bytecode ops aren't slow as molasses too, for similar reasons.
  - joaommartins 4y ago
    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?

d0mine 4y ago

As I understand, C extensions are used for CPU heavy work e.g., numpy is likely ported to WebAssembly.

tempay 4y ago
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. [1] https://jupyterlite.readthedocs.io/en/latest/ https://jupyterlite.readthedocs.io/en/latest/
codedokode 4y ago
No. People won't write C extensions. They will write something heavy like Redux (which recreates full object graph on every event) in Python.
- ivoflipse 4y ago
  You'll like what we've done during my Hackathon https://github.com/fork-tongue/collagraph/pull/66 https://github.com/fork-tongue/collagraph/pull/66 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)

summerlight 4y ago

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.

nerdponx 4y ago
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.
codedokode 4y ago
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).

bipson 4y ago

I think comparing it to C isn't fair. 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! Oh, wait.

danuker 4y ago
> Web "development" was never a thing for the greybeards Hacker News is written in some Lisp, and I spend more time here than on any bloated SPA. Reddit with the old UI is a close second.
- sevazhidkov 4y ago
  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).
  - Zababa 4y ago
    Hacker News does have a bit of frontend, written in JavaScript. You can see some here https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js, I'm unaware if it's everything or just a part.

raverbashing 4y ago

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

Panzer04 4y ago
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.
- codedokode 4y ago
  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.
codedokode 4y ago
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.

toyg 4y ago

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.

codedokode 4y ago
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.
- toyg 4y ago
  > 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.