Will I ever be able to code client-side browser code in a language of my choice?

Question

I'll be brutally honest: I hate writing client side code in JavaScript. I'm not a fan of this language, to say the least.

It seems silly to me that browsers support a programming language, rather than an intermediate virtual machine (like CIL or JVM). The latter would allow programmers to write in a language of their choice (to some extent), rather than in one fixed pre-set language. This language could evolve more rapidly, because only changes to the CIL/JVM/whatever would require every major browser to upgrade. Language features could be added without affecting old browser experience.

The massive savings of effort that intermediate langauges bring about are well known. Are there any initiatives out there to promote browser "scripting" in something other than JavaScript, and especially in an already designed, developed and optimized virtual machine? Do they have any momentum?

Answer 1

To answer your question, yes there are efforts being made to deprecate Javascript in favour of a more cohesive language for web scripting. Google have been putting a lot of thrust behind their Dart language. Dart has it's own VM which is already embedded into Chrome, but I'm not sure if the other browsers have adopted it yet. There is also a fairly promising language called CoffeeScript.

There's also a very ambitious looking project called HaXe which aims to unify a whole host of development platforms with a single language..

Believe me you're not alone in disliking Javascript, but I'm afraid it's not going anywhere soon - in fact it seems to be gaining a lot of momentum what with Windows 8 HTML5/JS apps etc.. but alternatives like the ones I mentioned are starting to spring up :)

Answer 2

Essentially, no. You're pretty much stuck with Javascript.

Having said that, there have been efforts in the past to bring other languages on board (java applets, vbscript, etc.) Each of these never really gained the traction that javascript has because javascript is integrated.

The only way to build what you are referring to would be to create a scripting language that runs on a virtual machine, compiled client side, and then executed. Then each browser would have to implement the virtual machine into its own codebase so that all the code ran on all the browsers. Then you'd have to make sure to have some sort of standards so that all the browsers executed the commands the same way. Of course, browsers being independently created, there would probably be quirks that the developers would have to keep in mind.

But now we've just described Javascript.

So in the end, your choices are:

1. get used to Javascript
2. try to use some language that compiles down to Javascript. (Keep in mind that you will still want to verify the Javascript, which puts back to option 1.)
3. use a language that exists as a plug-in to the browser, such as actionscript (Flash), ActiveX, java applet, .Net (SilverLight). This avoids the problem with multiple vendors/implementations of the language, but doesn't integrate the language.

Essentially, if you want an integrated language, you're stuck with Javascript.

Answer 3

Javascript itself can be viewed as being an intermediate language, defining a virtual machine into which other languages can be compiled. In projects like GWT this notion is already taking off. It might not be what you'd design from scratch, but it's already becoming a reality that you could compile "your favourite language" into Javascript.

Answer 4

In fact you're not hating javascript, as described in Ecma standards, but you're hating the awful implementation across various browsers, with they quirks, bugs and wtfs. Server-side Javascript is quite enjoyable actually. Also the DOM Model is the cause of 80% of the pain of client-side javascript.

If you still want to use another language, you can use GWT, which basically let you write Java, then compile it into (ugly) javascript, or CoffeeScript, which is a syntactic sugar over JS, that compiles into JS.

Answer 5

This question pops up from time to time.

Why don't we have other languages in script tags instead of just Javascript

Back in the day IE introduced VB as an alternative to Javascript. I think you can already see how this would lead to standards hell if it caught on...

So why not a common standard intermediate language then?

There is an old podcast from Brendan Eich explaining why he doesn't see an intermediate bytecode language in the near future:

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

The basic problem is that while the intermediate language (like CIL & the JVM bytecodes) tries to be generic, most of they time they turn out to be too low level and too bound to the original high level languages that compiled to them. For example, you can't really implement tail recursive functions in the JVM - what other language features or implementation choices will we be unable to implement if we couple to a low-level bytecode abstraction too early?

Meanwhile, Javascript is a flexible high level language with extablished semantics and multiple, different, efficient implementations. What we might see in the future is Javascript itself as an intermediate language - Unfortunately this is somewhat immature and few languages compile to JS as of today.

Answer 6

Yes. You can already compile Dart, Coffeescript and Java to Javascript. You have Emscripten, which is a compiler backend for LLVM for generating Javascript bytecode (and LLVM handles quite a few languages, I believe).

But other than compiling to JS, not in a short time frame. IE6 is 10 years old and still kicking. I hope that current browsers (which do not support other languages) won't survive so long, but they'll be around for a few years, provoking the tail-biting cycle of "we still have to support browsers which only support Javascript, so we have to use Javascript", in a much harder way than say CSS3- your site might work without CSS3, but try making it work without client-side scripting.

Answer 7

You might just be in luck. This is the opening paragraph of a submission on the webkit-dev forum:

Many languages compile to JavaScript today to run on the web. As alternative, we’ve been experimenting with enabling different language runtimes in WebKit to run in web pages alongside JavaScript...

You can view the rest of the message here.

Answer 8

JavaScript is the very soul of browsers, thats why the majority of new attempts are generating JavaScript (CoffeeScript is a clear example).
In GWT, you code your client-side logic in Java programming language and the toolkit with generates JavaScript.

ClojureScript is an interesting project if you are in Lisp coding.

So it looks no matter what, JavaScript is here to stay. (COBOL of the web maybe?).

Answer 9

"Any customer can have a car painted any colour that he wants so long as it is black." -- Henry Ford

There are already a number of compilers that target javascript, and you can pick any language that compiles to javascript.

Your link discussing the value of intermediate languages discusses them in the context of implementing a compiler suite, not in providing code that will be shipped across a network and run on a client machine. Javascript may not be the best format for that, but whatever is, it won't look much like CIL or java bytecodes.

If you hate javascript, I suggest you move into the Embedded, Scientific, or game development space, where C, Fortran, and C++ rule the roost. Line of business apps are very much moving to the web, and that means more Javascript, not less.