We don't need Python in the browser. We need x in the browser, where x is every language and runtime.
Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are languages that are arguably more expressive than it.
The problem is right now, only browser makers get to decide what languages run in the browser. Browser makers have their own concerns, and supporting new languages hasn't been historically among them.
What would be nice to aim for is a model where browsers can support multiple language runtimes. Instead of the browser makers being the ones to support a language, that language's advocates would be responsible for the port - and I suspect the competition and cooperation would make them stronger.
Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
This would let Python, Ruby, Haskell, Scala, Closure, Java, non-legacy Javascript, and more exist in the same browser, giving the web platform the same diversity of languages as is available on the desktop.
(Mobile platforms seem to also have this problem. The recent move from general-purpose to language-specific platforms is sub-optimal.)
> Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
Native Client works behind a plugin API. That means all the languages you implement in it don't integrate as well with the web as JS does. For example, holding references to DOM notes, cycles etc. would work differently.
So I'm a little ignorant, but I think I'll benefit from answers more informed people give:
My question is, why aren't people out there (who are more experienced at programming/developing than I am) developing support for X language(s) in open source web browsers like Firefox. I'm sure I don't fully understand how this works yet, but can't anyone who wants to be developing this capability independently instead of waiting for browser makers to do it?
That's a good point; does that imply that it can't be incorporated after the fact? That if a number of dedicated users applied it to the product themselves, the browser makers wouldn't come around to incorporating it?
Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are languages that are arguably more expressive than it.
The problem is right now, only browser makers get to decide what languages run in the browser. Browser makers have their own concerns, and supporting new languages hasn't been historically among them.
What would be nice to aim for is a model where browsers can support multiple language runtimes. Instead of the browser makers being the ones to support a language, that language's advocates would be responsible for the port - and I suspect the competition and cooperation would make them stronger.
Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
This would let Python, Ruby, Haskell, Scala, Closure, Java, non-legacy Javascript, and more exist in the same browser, giving the web platform the same diversity of languages as is available on the desktop.
(Mobile platforms seem to also have this problem. The recent move from general-purpose to language-specific platforms is sub-optimal.)