If you already have a lot of domain logic in Python for your backend, that would make it easier to write a frontend living in the same codebase. (For example, imagine a framework for autogenerating forms for your Django models; this already exists server-side, but native client-side Python would give you more options. And if your framework owns both the client and server, it could autogenerate the API so you don’t even need to write one for happy-path usecases.)

If you are already using Python on the backend, not having to hire/train a completely different skill set/stack is appealing. Sure, the browser and CSS/HTML specialism is going to remain, but not having to split your team by JS vs <backend-language> would make it much easier for a team to collaborate and share work.

I think Python in the browser only has to be “almost as good” in a direct comparison for it to actually win out as the best choice organizationally for many teams.

I'd say that there's less knowledge shared between Python frontend and Python backend than between Python and JavaScript frontends. Outside of syntax and ecosystem, I wouldn't think there's much shared between Python backend and frontend.

It makes no sense to me also. One of the reasons Python so popular is due to it's interoperability with libraries written in C/C++, otherwise it's just super slow language. In the browser you can't access these fast libraries so you are left with a crap language with an even slower execution due to the interpreter VM written in JS

There are a huge number of people who would disagree with Python being a "crap" language, and the irony is that the only language supported in the browser is js. You're missing a big reason Python is popular, and it is another reason this is a big deal. The number of people that have an opportunity to make web apps opens a great deal.

Also the idea is you CAN now access those libraries like numpy, even though Python speed in general is usually overstated.

> Why?

This isn't good for most web use cases but there are some major new use cases that it enables.

Pyodide is in Python documentation all over the place, for instance on https://numpy.org/

Python has many libraries that JS is missing. Particularly the scientific computing ecosystem has a lot of very well supported Python packages but fewer JavaScript packages. They also can benefit a lot from connection to a UI.

Two key use cases for this stuff are Python education and scientific computing. Students have a hard time installing Python locally. Generally scientists want to share their results broadly, but they probably did their analysis in Python.

Here's another example of a good use case: https://www.socialfinance.org.uk/blogs/analysing-sensitive-d...

To be clear these are all use cases of Pyodide. PyScript only was released two days ago so it's harder to point to real world uses.

I think it's primarily meant as a learning tool. Here's the TL;DR from their GitHub.[1]

PyScript is a Pythonic alternative to Scratch, JSFiddle or other "easy to use" programming frameworks, making the web a friendly, hackable, place where anyone can author interesting and interactive applications.

https://github.com/pyscript/pyscript

Ah that makes sense, I didn't think of that. Thank you.