Why did Google develop a cross-compiler from Java to JavaScript? [closed]

Question

Google developed a cross-compiler from Java to JavaScript. Why did they do this? Does this mean that JavaScript is not good enought for developing advanced web apps?

Answer 1

They provide part of the answer on this page:

http://code.google.com/webtoolkit/makinggwtbetter.html

To start with the basics, why does GWT exist in the first place? The short answer is that GWT exists to make the web better for users. We've infused a slightly longer answer into our mission statement:

GWT's mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.

In other words, it was a way of getting Java developers to write Ajax-heavy apps.

Answer 2

Because at the time, people didn't see any value in learning JavaScript, JavaScript lacked a large implementation base (though it's got the largest install base out there!), and in general Java programmers seem to prefer programming in Java more than anything else.

Answer 3

Java is a compiled language with a variety of mature tools and a large developer community. It has types, objects, exceptions, frameworks, great tools, community support, etc.

JavaScript has all of these things too - except for the compilation.

If you could compile your code, thoroughly test it in Java and then translate it to something the client can run (i.e. JavaScript - I'm guessing VBScript had no chance here) then it'll reduce the overall development costs. Developing large, complex AJAX applications like GMail is expensive.

There are many "write in one language, run in another" techniques around - but this was a good one.

UPDATE

To clarify my point further, JavaScript is an interpreted language where the parser will check syntax, but not pick up semantic errors such as:

function f(x) {
  g(y);
}

where neither 'g()' nor 'y' exist. This will only be picked up at runtime.

There are many JavaScript Engines such as V8, Nitro (JavaScriptCore) and Spider/Jaeger/TraceMonkey which will do a fantastic job of parsing and running the parsed code as fast as possible (perhaps by emitting machine code), but won't catch the semantic errors that a full compilation process would. This is often because scripts are delivered to the web browser independently of each other and the JavaScript Engine doesn't have the whole story until all of the required scripts have been downloaded/cached, the DOM has been initialised and any dynamically-generated scripts have been triggered. So the engine normally cannot have the whole source until quite late in the download and render process.

A full compiler will highlight the above code snippet as an error, which is one motivation to use a compiled language, verify correctness, perform unit tests and then use reflection or decompilation to generate the verified-correct JavaScript to run on the client.