If we can integrate a Python compiler directly into the browser ...

that's what Pyodide and MicroPython do: they bring the native interpreter toWASM which "compile" at runtime just like Python does.

The claimpyscript is very slow is a bit lame to me:

• it's bad for search engines results
• this discussion provides zero evidence around why, where, how it's slow ... there's nothing to work on for this team
• it's unnecessaryFUD we don't need, specially if you appreciate the project

Most importantly, the plethora of demos out there based on WebGL games to complex data-visualization applications would beg to differ your conclusion but it's true that we know some area could improve, yet it has nothing strictly to do with PyScript:

• MicroPython starts up in a matter of few milliseconds, that's the equivalent of any React app bootstrap
• Pyodide takes 1 to N seconds to bootstrap but once it does bootstrap, it's as fast as it can go (and standard CPython, so a bit slower thanMicroPython but fully CPython compliant)

TheWASM target/runtime lackscooperative GC andJIT but this has nothing to do with PyScript and it's not evenPyodide orMicroPython fault so ... what you are suggesting should rather land atWHATWG as it's a request for browsers/vendors, not for this team, we can't decide what browsers ship out there.

As summary, I think we should quickly edit the title of this discussion as it does a bad job at proposing anything concrete or addressable by the PyScript team but I'll wait@ntoll thoughts in case he has a different opinion.

Hey hey@MominIqbal-1234 - thank you for the feedback and kind words, it's really appreciated.

So, performance. 😄

That's a difficult nut to crack.

As@WebReflection pointed out, there are lots of complex factors related to the performance of PyScript. It is not enough just to say, "PyScript is very slow"... because I want to reply by asking, "compared to what, and in what dimension of measurement?". 😉 Does it start quickly? That depends on the runtime and (crucially, something over which we don't have control) network latency on first load. Does it evaluate code quickly? The biggest factor is likely the quality of the code PyScript is evaluating - even the world's fastest computer coupled with efficiently compiled code will grind to a halt if the code itself is written to perform asO(2^n) in complexity. And there are other subtle "performance" characteristics that are qualitative rather than quantitative in nature. For instance, the fact that Python makes it easy to write code so the time spent by the developer to make stuff work (something that is financially very expensive) is likely to be less with Python than, say, C++. It's also easy to get obsessed by "performance" as a synonym for "speed" because it's easy to measure, check and test. But fast doesn't necessarily mean better. You might have the fastest platform in the world, but if it's a pain to use, it's not a great trade-off.

So, as always, the answer to the question of PyScript performance is, "it depends". 👍

My personal view is to ask, "is PyScript's performance, across many different quantitative and qualitative dimensions, good enough?" That these various dimensions interfere with each other means we have to think very carefully about the trade-offs of preferring one type of performance over another. Crucially this means we pay attention in an enlarged and broad minded manner - and NOT just focus on "speed" (again, of what? Startup, execution, interaction with the browser, compilation of bytecode etc..?)

These are important discussions to have, and we welcome your comment, but (if I may), I'll change the title from the rather loaded, "PyScript is slow" to "Thoughts about PyScript Performance", since this is less pejorative and more accurately reflects the subtle, nuanced and very Very VERY difficult task of engaging with the performance characteristics of PyScript. 🤔

So, let the discussion begin..! This is what open-source engineering is all about. We lift each other up. 🚀