#brython

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.

Of all the JavaScript Pythons, it is the most feature-complete and compatible (unlike Transcrypt or Skulpt), while still being reasonably integrated with the webpage rather than a rather insulated emulation of an existing Python (unlike pyodide).

And it has the very developer-friendly feature of letting the HTML contain

<script type="text/python">

...

</script>

which I think is just wonderful. Even though modern serious web development is increasingly moving away from nesting scripts into the HTML, and almost always has some kind of build step which you might as well use to transpile from whatever source language you prefer, so live interpretation of Python source in the browser is not necessary.

But there's a lot of value in developing live, iteratively, in a REPL, in the target environment, trying things, and having an extremely quick feedback loop between writing code and seeing what it does.

And another nice thing about Brython is that it is so simple to use - just

include the Brython .js file,

if you need it, include the Python standard library .js file, which you can strip down to just the modules you need with a command that Brython ships,

run the `brython` function once the document is loaded enough for it to see your Python scripts, and

boom, script away, whether in the HTML or in separate .py files.

And those Brython .js files are already published in CDN servers (and you can pin the version you want in the URL) so you don't have to download and host it yourself, which in some ways is arguably better because as more websites use it, you get amortized cost savings since your browser will already have the script cached from the CDN and not need to load it again. It also means you can ship "standalone" interactive HTML files scripted in Python.

看到「A Python 3 implementation for client-side web programming」這個專案，在瀏覽器裡把 Python 程式碼用 <script type="text/plain"></script> 包起來，然後掛個 js 進去，就可以在瀏覽器裡面跑 Python 操作 DOM：

Brython is designed to replace Javascript as the scripting language for the Web. As such, it is a Python 3 implementation (you can take it for a test drive through a web console), adapted to the HTML5 environment, that is to say with an…