An aimless rambly post about in-browser Pythons, with the approximate theme of:
I think I'd recommend PyScript at least as much as Brython for quick practical Python-in-the-browser web development if you don't really need to optimize performance.
PyScript is much more "heavy" since the underlying Pyodide is a full compile of CPython to WebAssembly, plus libraries, one of which gives it a built-in ability to download modules from PyPI from within the Python running in your browser. The heaviness and slow load time used to annoy me, but it buys you much more compatibility and certainty of compatibility with CPython.
The killer feature for me is being able to just import most packages that you might want to use without any of the hassle of "how do I get this into the browser?". Just `await micropip.install(foo)` in your browser-side Python code before `import foo` and you're good to go. Python has always been the language you reach for, first and foremost, when you strongly prefer to optimize for developer time+work instead of computer time+work, or when you want a great ability to tinker or modify code in situ. And doing something resembling "pip install" in the browser is very much a good example of that.
Right now, if you wanted to use one of my Python modules on Brython and you didn't know where to start, I'd have to write several sentences - grab the source, put it over there, maybe run the right brython-cli command to bundle it. If you want to use one of my Python modules on PyScript, you just grab it from PyPI with micropip and it just works (barring some edge cases which I recently helped them fix, which is in micropip v0.2.0 already and should be coming to Pyodide in v0.22).
One thing I liked about Brython is that it ships with some quality-of-life improvements for manipulating the DOM through its `browser` module, which tries to provide some ergonomics that you can't get in JavaScript for lack of operator overloads and the like. But PyScript has a good enough FFI to JavaScript that we can just start with the DOM manipulation that we would do in JavaScript, and then code whatever Python ergonomics we want around it (which could then just be uploaded to PyPI).
I also have mixed feelings about how PyScript gets all over the HTML namespaces - tags like `<py-script>` and `<py-config>`, attributes on HTML elements like `py-onclick` or whatever, that kind of thing. It's adding complication/coupling/non-orthogonality to buy a little developer experience friendliness. It feels fine now but I expect it'll prove clunky and annoying over time in various little ways - although to be fair, that's a problem that in part requires browsers and web standards to solve, and once that's standardized it shouldn't be too hard to migrate.
PyScript load times and download size can be pretty bad, but they're working on it. Admittedly an inherently hard problem, but I still think in the long term that gets solved out-of-band. Anecdotally, comparing the Brython website's demo REPL and the Pyodide (which PyScript uses) website's demo REPL, Brython loads perceptibly faster. But I haven't done any hard thorough measurements for real-world websites. For example, Brython lets you build a .js file with just the modules you're using, while the REPL on their website includes the whole standard library just in case. I'm not sure what PyScript's story is for that, but the out-of-band solutions are obvious and similar - bundlers and so forth.
Thing is, if you're really angling for performant Python-in-browser, you either transpile Python to JavaScript (something like Transcrypt, trading some semantic/feature consistency for speed), or you compile your Python to WebAssembly (conceptually something like Cython+Emscripten, but I haven't tried it or looked into how to actually do it) - and if you do that last thing, well incidentally you can upload that as yet another pre-compiled WASM wheel to PyPI which can then be used with PyScript too. And that looks a lot like the modern Python world where CPython speed is fine and if it isn't you compile the hot path Python code into native code.
Just like the Python of old, it will be one of the slower languages on the block for a while. Longer start up or page load times, more memory usage, more overheads all over the place just in case you're using the dynamic flexibility at execution time. That's fine. Humanity used Python twenty years ago, and it was fast enough for many uses. Today I think PyScript is in a similar boat. It will be slow, at first. That's fine. People will use it when they need to go fast, when the productivity or expressiveness or flexibility benefits of Python matter more than the fact that the page took a little while longer to load. Especially since you might be writing a web page that gets opened once and then stays open for hours or days on the user's computer.
Slowly but surely the automatic optimizations will catch up, and in the meantime, PyScript seems like the best contender for the cases where you want Python, not almost-Python but really Python, in the browser.
