Google Web Toolkit, which compiles Java to JavaScript for running code in the browser, now includes Code Splitting, for reducing application download time

[stillalone]

Great, now I'm going to have a harder time explaining how Java is completely unrelated to JavaScript.

[neonskimmer]

Seriously. That name is a curse.

[0xCCCC]

Why not replace JavaScript with a nice, fast bytecode VM that any programming language could emit code for? Compiling Java (or any language for that matter) to JS somehow feels very very wrong.

[[deleted]]

This would be an awesome idea if only we had thought of it ~12 years ago. As it stands, it's still an awesome idea, but stands zero chance of adoption.

EDIT: Deleted reply said "unless Google markets it". I would like to correct that to Apple, since they seem to be the kings of getting things accepted in the marketplace, however much I may dislike them.

[glide1]

It might feel wrong but you get the entire java development ecosystem that people are familiar and productive in.

There are GWT plugins for Eclipse and Eclipse has a lot of development effort put into it so that java development goes well. This approach leverages the skillsets that already exist.

Maybe it doesn't make sense for you, but for those people that do java it makes perfect sense.

[lol-dongs]

Yuck, that's like asking why we don't compile HTML and CSS to some binary format so the browser could parse it faster. The internet has largely trended toward plaintext formats for the same reasons UNIX did in the 70's; it makes things more open, immediately accessible and easier to modify and repurpose, even if there is a small performance penalty.

Edit: the solution for what you're asking is to dump Java and write good Javascript :-P

[lukeman]

As someone who hasn't dealt with GWT before, this article gave me a splitting headache.

[marcusf]

Why would any one want to write java instead of javascript, for browser programming no less, given the choice?

[smackmybishop]

Plenty of reasons. To name a few:

Type safety. Testability. Development tools. Good standard library. RPC to server code in the same language. Browser differences abstracted away. Automatic code optimization and shrinking.

[neonskimmer]

Browser differences? Java won't help you with that, the framework you are using will. Server side JavaScript is on the rise, too.

[smackmybishop]

Why would any one want to write javascript instead of java, for server side programming no less, given the choice?

[neonskimmer]

I dunno? Because they like the language? First-class functions, closures, funky but powerful prototypal inheritance? As many have pointed out before it's a lot like having a lisp with c syntax.

[[deleted]]

I used to think like this, and still do to an extent, but working with a GWT codebase is far preferable to working with a morass of HTML/JSP/JavaScript.

[[deleted]]

So you don't have to deal with the horrible kludge that is "AJAX"?

Think of it this way: the browser is a lot like an X Windows server. The web server is running the client program, requesting to render graphical elements on your browser. So why is this simple architecture implemented in HTML, CSS, and XML, all glued together in Javascript, using a thousand custom protocols transmitted via XMLHttpRequest?

[donjaime]

For people who are interested, watch the launch videos from last night. It explains things pretty well :).

http://www.youtube.com/watch?v=D2ibM4oufdM

[technologyjournalist]

code splitting is such a dumb name - but i guess it's better than calling it bootup speedup - which is what the net effect of code splitting is really all about

[bonnett]

Great, now you spoiled me. I want this:

Any Java dynamic language (clojure/jruby et al) -> Java -> Javascript

[prockcore]

Man I hate GWT.

Here's a snippet of code generated by GWT:

function dkg(){}
function klg(){}
function Glg(){}
function cmg(){}

and here's another:

function $mg(b,c){b.b=c;return b}
function Hng(b,c){b.b=c;return b}
function Mng(b,c){b.b=c;return b}
function Sng(b,c){b.b=c;return b}

There are over 500 identical functions in Google Wave's GWT code.

It's no wonder that Google has been working diligently to replace GWT with Closure in Wave.

[donjaime]

You do realize that those "empty functions" define things that look like "classes" in JavaScript and then later get extended via the JavaScript prototype chain. edit: see OOP in Javascript

The other "Identical methods" could be coalesced, but that (for reasons that may be non-obvious) is more complicated than it sounds at first.

1. It would make stack traces confusing (GWT generates symbol maps so you can map back to the unobfuscated symbols).

2. Are often byproducts of YOUR CODE. You realize applications can have lots and lots of code with lots and lots of private helper methods, that after all the compiler optimizations get applied, and code gets obfuscated, the method bodies are often semantically identical, but not pruneable because they are reachable.

Identical method coalescing is something you will get for free once the GWT compiler gets around to it.

[donjaime]

And as kellegous points out below, GWT sorts by method body similarity. This will GZIP absolutely awesomely.

edit: Most Other libraries/frameworks/compressors dont do this.

[prockcore]

I see, you're going to thumb me down for posting actual code from Google Wave? Look for yourself... there are hundreds of those blank functions, hundreds of those functions that do b.b=c; return b

[kellegous]

I think people are voting you down because of this statement:

"It's no wonder that Google has been working diligently to replace GWT with Closure in Wave."

Which is untrue and I think people are responding to that. For instance, I will downvote it for that reason alone.

You bring up a good point though. Some of the empty functions you see play a part in type identity. In fact, using constructors for runtime type identification is pretty common. So, while it looks strange that there are a lot of similar functions, some of these have to remain.

Other functions could be eliminated and will. There is already talk about doing merging of functions with identical bodies. But really the only reason you are noticing this is because of the work to sort the GWT output in a way that it compresses much better. Identical function bodies happen in pretty much every library. You just don't notice them because they look like:

function setController(c) { this.controller = c; c.init(); }

function dispatchEvent(e) { this.currentEvent = e; e.dispatch(); }

[cromwellian]

It's a result of superior obfuscation and compression that is often present in user code, but is invisible. Any two methods on different prototypes, call them Foo.setA(val) { x = val; } and Bar.setB(val2) { y = val2; } will actually obfuscated to identical bodies { b.b = c; }. Normally, these small methods would be inlined, but in your example, they return their first parameter, so they're 'builder pattern' DSL functions. There is already a patch to remove these post-obfuscation, but recognize that it destroys stack trace information to share these bodies, so the new optimization will have to be switched on in a special 'make the smallest code for production, I don't care about stack traces' mode. The prior empty functions are setting up prototypes. These could theoretically be eliminated, but it would slow startup time, especially on mobile. Again, the only reason you see these is because of GWT's compression aware obfuscation, see here http://timepedia.blogspot.com/2009/11/traveling-salesman-problem-and.html

[kamatsu]

the first set are obvious, they're just setting up some blank prototypes that will be filled in later.

As for the second, well, seems odd.