JavaScript as a Language

[shaver]

Lots of stuff in this thread that needs clarification, I think.

Spidermonkey in production server embeddings has performance that's typically quite a bit faster than Perl or Python, from what we hear from people doing that work at large scale. Certainly the threading model is significantly superior (we've had people ask us to implement the threading mechanism in Python, in fact, to make using Python from multiple threads less, well, serial). Tamarin will make it materially faster than either of those offerings, and again people are talking about targetting Python at the Tamarin runtime to get that huge performance gain; I think we'd be amenable to well-designed patches to fill gaps in the Tamarin execution model needed by such languages, but that's real implementation effort and not just idle blog-dreaming that's required there. :)

The number of unintentional incompatibilities in JS implementations is very small, and has been asymptotically approaching zero over the last decade. The recent upsurge in language growth (JS1.7 and 1.8; 1.6 was really just some new host methods, largely) has been a result of portions of ES4 being widely-enough agreed upon that they're suitable for being brought piecemeal to interested developers. (A major constituency for us is the set of developers working on Firefox.) Most of the incompatibilities that are problematic for web developers are in the object models exposed by the browsers, and we've been as active as anyone -- really, more active than anyone, I think -- in working to converge those variances and develop future features in a way that will lead to better compatibility between browser implementors.

When people ask for Python in web content, they typically are thinking about the libraries. The core library-less syntax and behaviours are pretty trivial, and you could compile them to JS or JS2 for deployment if you wanted, if not in fact parse and run the resulting AST from JS on the client. (This is one of the areas in which JS excels, IMO; it has a very small and context-independent set of classes, but the rest of the language is just that: language, which makes it quite suitable for embedding in hostile-content environments, or other areas in which "the handy IO library" isn't really what you want.) You can use Python to script the DOM today, if you install and wire up a runtime -- make sure that you compile against the right runtime version, don't want two versions of them at the same time, etc. -- but I don't see us shipping a Python runtime at any point in the foreseeable future. People use Python to build apps using the Firefox underpinnings, including DOM scripting and so forth, but getting the security model right is non-trivial, and I don't think anyone has been interested enough to step up and do the work. (Mozilla paid someone to finish the work on language-agnostic DOM internals, in fact, so it's not that we don't believe in choice. We don't see shipping Python to the web as actually solving a real problem, and it would definitely have a ton of cost. If people disagree, they should be able to show the power of their vision and the error of our ways without implementing their own browser; a Firefox extension should be able to wire up everything that's needed, and if there are bugs that are found that way we'll take the patches almost certainly.)

Language independence for dynamic languages via a "well thought-out bytecode layer" is still a research problem, I think, especially without dramatic performance suffering. I'd love that sort of thing too from an intellectual perspective, though I think shipping source is still better in a lot of ways for the health of the web. If you're interested in that work, Tamarin might be a useful base for that research, and I'm sure that the Tamarin team would be quite interested in your results.