It's politics, not technology. One could make a browser scripted via python, but it would be an extreme minority position and would fail to gain adoption. One could add python support to any existing browser, but none of the stakeholders care enough to do it; they will always argue it is a waste of time because <insert other popular browser> doesn't do it.

There is nothing about JavaScript that is uniquely suited to the browser, it just "won out". It's hard enough to get browser vendors to agree to standards at all, say nothing about multiple standards for a single feature.

I think the lesson that the last few years have taught us is that you can do ambitious things, but to get buy in it needs to be an incremental and gradual. This is the cost of a large system with >4 largely independent implementors with significantly distinct plans and goals.

It's not too hard for me to imagine a near future with smooth python support in the browser. A webassembly python runtime with GC integration in the browser served trustlessly and with a high cache hit rate from a CDN using subresource integrity (and perhaps with even the popular runtimes packaged ahead of time in browsers). It might be possible to load and run the python source through the webassembly runtime using the ES6 module loader. I wonder if we'll even see JITs in webassembly-based interpreters that compile code that they're interpreting down to webassembly.

> I wonder if we'll even see JITs in webassembly-based interpreters that compile code that they're interpreting down to webassembly.

Almost certainly. PyPy.js does this with asm.js today.

> There is nothing about JavaScript that is uniquely suited to the browser

There are, however, features about JS VMs that make them (almost) uniquely suited to browsers. Most notably, almost any other VM has a stdlib including things like open() for local system files — and that'd be considered a massive security exploit. Some languages have features (v. parts of the stdlib) that are insecure in the browser setting — for example the backticks operator in Python. Ensuring an existing VM has had all access to the local system closed off could easily turn into a massive project in and of itself.

> It's hard enough to get browser vendors to agree to standards at all, say nothing about multiple standards for a single feature.

I don't think that's fair — I don't think there's many cases of major browser vendors acting maliciously towards standards in recent times, the only particular examples that stands out to me are the whole pointer/touch events debacle (with Apple withholding patents from the W3C Patent Grant) and the AV codecs mess with various vendors acting selfishly. Otherwise, almost everything seems to be genuine disagreements about how best to do things, especially given market realities.

What was insecure about the backticks operator? (that doesn't exist anymore in Python3 anyways)

Politics ? I bet many programmers would like to develop their code for one browser if it supports python. If many apps are only supported by firefox because of that, users might just install firefox if it has an edge in term of app quality and quantity.

That's like why developers chose to use linux to develop web applications, and people used those websites, they did not stick to windows software solutions.

It's really important, I think, to keep having different technologies available so that developers can choose what is better. There are many python programmers already, the language is mature and used in many places and I'm sure it could be used in more places.

> why javascript is better suited for a browser than python

Blocking?

That isn't really related to language as much as it is to the API. JS is crap at handling asynchronous programming compared to Python (until it gets async/await/generators which Python already has) but most of Pythons standard library has blocking APIs.