Why JavaScript rather than a standard browser virtual machine?

Question

Well, yes. Certainly if we had a time machine, going back and ensuring a lot of the Javascript features were designed differently would be a major pastime (that, and ensuring the people who designed IE's CSS engine never went into IT). But it's not going to happen, and we're stuck with it now.

I suspect, in time, it will become the "Machine language" for the web, with other better designed languages and APIs compile down to it (and cater for different runtime engine foibles).

I don't think, however, any of these "better designed languages" will be Java, Python or Ruby. Javascript is, despite the ability to be used elsewhere, a Web application scripting language. Given that use case, we can do better than any of those languages.

I think JavaScript is a good language, but I would love to have a choice when developing client-side web applications. For legacy reasons we're stuck with JavaScript, but there are projects and ideas looking for changing that scenario:

1. Google Native Client: technology for running native code in the browser.
2. Emscripten: LLVM bytecode compiler to javascript. Allows LLVM languages to run in the browser.
3. Idea: .NET CLI in the browser, by the creator of Mono: http://tirania.org/blog/archive/2010/May-03.html

I think we will have JavaScript for a long time, but that will change sooner or later. There are so many developers willing to use other languages in the browser.

Answering the question - No, it would not make sense.

Currently the closest things we have to a multi-language VM are the JVM and the CLR. These aren't exactly lightweight beasts, and it would not make sense to try and embed something of this size and complexity in a browser.

Let's examine the idea that you could write a new, multilanguage VM that would be better than the existing solution.

• You're behind on stability.
• You're behind on complexity (way, way, behind because you're trying to generalize over multiple languages)
• You're behind on adoption

So, no, it doesn't make sense.

Remember, in order to support these languages you're going to have to strip down their APIs something fierce, chopping out any parts that don't make sense in the context of a browser script. There are a huge number of design decisions to be made here, and a huge opportunity for error.

In terms of functionality, we're probably only really working with the DOM anyway, so this is really an issue of syntax and language idom, at which point it does make sense to ask, "Is this really worth it?"

Bearing in mind, the only thing we're talking about is client side scripting, because server side scripting is already available in whatever language you like. It's a relatively small programming arena and so the benefit of bringing multiple languages in is questionable.

What languages would it make sense to bring in? (Warning, subjective material follows)

Bringing in a language like C doesn't make sense because it's made for working with metal, and in a browser there isn't much metal really available.

Bringing in a language like Java doesn't make sense because the best thing about it is the APIs anyway.

Bringing in a language like Ruby or Lisp doesn't make sense because JavaScript is a powerful dynamic language very close to Scheme.

Finally, what browser maker really wants to support DOM integration for multiple languages? Each implementation will have its own specific bugs. We've already walked through fire dealing with differences between MS Javascript and Mozilla Javascript and now we want to multiply that pain five or six-fold?

It doesn't make sense.

On Windows, you can register other languages with the Scripting Host and have them available to IE. For example VBScript is supported out of the box (though it has never gained much popularity as it is for most purposes even worse than JavaScript).

The Python win32 extensions allowed one to add Python to IE like this quite easily, but it wasn't really a good idea as Python is quite difficult to sandbox: many language features expose enough implementation hooks to allow a supposedly-restricted application to break out.

It is a problem in general that the more complexity you add to a net-facing application like the browser, the greater likelihood of security problems. A bunch of new languages would certainly fit that description, and these are new languages that are also still developing fast.

JavaScript is an ugly language, but through careful use of a selective subset of features, and support from suitable object libraries, it can generally be made fairly tolerable. It seems incremental, practical additions to JavaScript are the only way web scripting is likely to move on.

I would definitely welcome a standard language independent VM in browsers (I would prefer to code in a statically typed language).

(Technically) It's quite doable gradually: first one major browser supports it and server has the possibility to either send bytecode if current request is from compatible browser or translate the code to JavaScript and send plain-text JavaScript.

There already exist some experimental languages that compile to JavaScript, but having a defined VM would (maybe) allow for better performance.

I admit that the "standard" part would be quite tricky, though. Also there would be conflicts between language features (eg. static vs. dynamic typing) concerning the library (assuming the new thing would use same library). Therefore I don't think it's gonna happen (soon).