15

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?

Improve this question
2

9 Answers 9

Reset to default
12

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 :)

Improve this answer
7
  • 9
    Unifying everything into a single language is exactly the opposite of what’s desired. It only leaves you with the same situation as now, just with a different language instead of JavaScript. The point is that existing efforts should be built upon: IL/CLR is well-established, already has high-performing JITters for most platforms, and several compilers already compile several languages into it. To bring the web into the 21st century, browsers need to make use of that, instead of constantly trying to bake their own new stuff and starting from scratch.
    – Timwi
    Dec 14, 2011 at 15:14
  • 3
    @Timwi, CIL is too heavyweight and there is too much of a bureaucracy in it. It would not make sense to attach a full, bloated bytecode file with a dedicated class and all the bulky metadata to each and every onSomething event handler - parsing and interpreting 10-20 characters of a simple scripting language is much more efficient.
    – SK-logic
    Dec 14, 2011 at 16:25
  • 1
    @SK-logic: You seem to have a completely wrong picture of CIL, and of bytecode in general. I have no idea what would make you think that binary metadata is “bulky” compared to a high-level syntax like JavaScript. Most of all, I have no idea why the “each and every onSomething event handler”. C# programs clearly don’t compile into multiple assemblies for every event handler.
    – Timwi
    Dec 15, 2011 at 14:10
  • 1
    @Timwi, I'm eating ECMA-335 for breakfast, so I know all too well how bulky the CIL is. DOM nodes are often generated dynamically. There is no way to add something to an existing module in CIL - you have to define a new module. And you can't add to a class - you have to define a new class (with the bulky metadata attached). And just compare the cost of reading, JITing and executing CIL to parsing, executing and immediately discarding a tiny text string. There are many cases where an ad hoc interpretation is a way much more efficient than any kind of compilation.
    – SK-logic
    Dec 15, 2011 at 14:17
  • 2
    @Timwi, you're proposing to use the bytecode as the common denominator and a communication format, right? My point is that the current specification of the CIL is pretty much useless. ExpandoObject is irrelevant. And your view on parsing complexity is obscured. CIL module contains its own assembly reference table, metadata tokens table and only then classes and methods. Compare the effort required to read and JIT all this bulky stuff with interpreting a string of a trivial high level language. Parsing cost is nearly zero here. Just try both approaches and compare yourself.
    – SK-logic
    Dec 15, 2011 at 14:40
5

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.

Improve this answer
5

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.

Improve this answer
6
  • 2
    Another choice would be use a language that compiles to javascript and use that.
    – Jetti
    Dec 15, 2011 at 18:10
  • @Jetti Are you thinking of CoffeeScript? It's motto--it's "Golden Rule" as they call it--is "It's just Javascript". But if you're writing something that's essentially Javascript, aren't you really writing Javascript? It's like arguing that jQuery isn't javascript because it's cleaner and easier to use.
    – Richard
    Dec 15, 2011 at 19:09
  • 3
    take a look at this list of languages that compile to javascript
    – Jetti
    Dec 15, 2011 at 19:19
  • @Jetti Maybe they would work out alright. But with the quirkiness of cross-browser support, I would be nervous about recommending any of those and not verifying the actual generated javascript.
    – Richard
    Dec 15, 2011 at 19:39
  • 1
    Except that javascript is an utterly horrible intermediate language, and very hard to execute consistently.
    – Milind R
    Dec 2, 2014 at 13:49
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.

Improve this answer
8
  • 9
    I can’t speak for romkyns, but I hate JavaScript itself (in addition to the problems you mentioned). It is not object-oriented, has no static typing, no useful error handling, and no useful framework of modern functionality. It is also inconsistent and unwieldy. And by the way, the most hated feature of JS, semicolon insertion, is in the ECMA standard.
    – Timwi
    Dec 14, 2011 at 15:09
  • 1
    @Timwi, it's function based and you can write OO code if you want. Static typing is nice, but if your code is written well (small functions, proper scoping), it's rarely an issue. As for semicolon insertion, I find that to be a mild annoyance. It's only ever bit me once, because I had the return and opening { of an object on different lines. What "framework of modern functionality" do you find is missing?
    – CaffGeek
    Dec 14, 2011 at 16:10
  • 2
    JavaScript itself is not the best language out there (to put it politely). I do not care about object-oriented stuff (the less of it - the better), about its dynamic type system (it is really needed for a scripting language of this kind, unfortunately), but the presence of statements and the lack of proper lists and tuples is annoying. Both for writing in JavaScript and for implementing compilers that target JavaScript.
    – SK-logic
    Dec 14, 2011 at 16:12
  • 2
    @Timwi: you're seeing not objet-oriented as a bad thing, while it's not always the case. Please don't see OOP as the silver bullet of development paradigms. Functional approach, like JS or Scala are great too. You can have OOP in JS, but the main difference is that it's Prototype-based programming, instead of Class-based-programming. OOP is a broad name, and doesn't limit to Java/C#. Prototype based is different from Class-based, and well used, it's as powerful as Class-based.
    – Clement Herreman
    Dec 14, 2011 at 16:54
  • 2
    @ClementHerreman: JavaScript is not limited to client-side, but this discussion is about client-side. JavaScript is limited to prototype-based, which is a downside compared to IL which would let you use pretty much any language whatsoever.
    – Timwi
    Dec 15, 2011 at 14:18
2

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.

Improve this answer
2
  • But this argument applies to JavaScript just as much as it applies to JVM and CIL, doesn't it? :) The only thing going for JavaScript is that it's already supported by all browsers.
    – Roman Starkov
    Dec 15, 2011 at 13:41
  • The point is more subtle - Javascript is described in a higher level then most intermediate languages so implementations get more leg room in choosing what to do. (Of course, this is not all a sea of roses - I just wanted to point out that we are not the first to think about an IL for the web and that it is not that simple)
    – hugomg
    Dec 15, 2011 at 13:45
1

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.

Improve this answer
0

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.

Improve this answer
0

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

Improve this answer
0

"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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.