Why JavaScript rather than a standard browser virtual machine?

Why JavaScript rather than a standard browser virtual machine?

Would it not make sense to support a set of languages (Java, Python, Ruby, etc.) by way of a standardized virtual machine hosted in the browser rather than requiring the use of a specialized language — really, a specialized paradigm — for client scripting only?
To clarify the suggestion, a web page would contain byte code instead of any higher-level language like JavaScript.
I understand the pragmatic reality that JavaScript is simply what we have to work with now due to evolutionary reasons, but I’m thinking more about the long term. With regard to backward compatibility, there’s no reason that inline JavaScript could not be simultaneously supported for a period of time and of course JavaScript could be one of the languages supported by the browser virtual machine.


Solution 1:

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.

Solution 2:

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
Related:  Chrome console shows me “Navigated to http://localhost…”

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.

Solution 3:

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)

Related:  Uncaught Error: Invariant Violation: findComponentRoot(…, …$110): Unable to find element. This probably means the DOM was unexpectedly mutated

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.

Solution 4:

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.

Solution 5:

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

Related:  javascript Associate array

(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).

Solution 6:

If you feel like you are getting your hands dirty, then you have either been brainwashed, or are still feeling the after affects of the “DHTML years”. JavaScript is very powerful, and is suited well for its purpose, which is to script interactivity client side. This is why JavaScript 2.0 got such a bad rap. I mean, why packages, interfaces, classes, and the like, when those are clearly aspects of server-side languages. JavaScript is just fine as a prototype-based language, without being full-blown object oriented.

If there is a lack of seamlessness to your applications because the server-side and client-side are not communicating well, then you might want to reconsider how you architect your applications. I have worked with extremely robust Web sites and Web applications, and I have never once said, “Hmm, I really wish JavaScript could do (xyz).” If it could do that, then it wouldn’t be JavaScript — it would be ActionScript or AIR or Silverlight. I don’t need that, and neither do most developers. Those are nice technologies, but they try to solve a problem with a technology, not a… well, a solution.