Google Web Toolkit

Google has released a new web toolkit. The possible significant item for LtU is the Java-to-Javascript compiler that is one of the central components of the toolkit. I am unconvinced of the value of coding in java rather than in javascript. However, the marketing folks have been thinking along the same lines as some of the threads here on LtU with respect to static type checking, code completion, etc. Maybe some of the static fans could comment on this?

cheers,
Jess

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

They should hire me...

Meta-Linguistic Abstraction as Compatibility-Code Encapsulation

The subject line says what I think Google has done here. They observed that cross-browser Javascript is a pain and that with AJAX you're basically calling server-side logic anyway, so why not encapsulate the cross-browser cruft in a meta-language, and since you're calling the server anyway, why not make the meta-language the language the server uses? This seems deeply pragmatic to me: your HTML/CSS wonks get to continue doing what they do best; your Java wonks get to continue doing what they do best, and neither of them has to worry about IE6 vs. Netscape 7 vs. Firefox 1.0 vs. Firefox 1.5 vs. Safari 1.2...

your HTML/CSS wonks get to

your HTML/CSS wonks get to continue doing what they do best; your Java wonks get to continue doing what they do best

True, my DSL approach doesn't buy you this compatibility. It can buy lock-in, though :-)

Somehow like haXe

HaXe tries to do something similar: it is a Java-like statically typed language, that can be compiled either

  • to neko-bytecode (discussed before) to run standalone or under mod_neko on the server,
  • to Javascript to run in the browser,
  • or to ActionScript to run in a Flash animation.

The nice point is that you can pass objects that are compiled from the same source form the client to the server and back (if they don't contain things like DOM nodes or database handles that make no sense on the other side).

There seems to be a trend here, with a whooping number of two projects doing similar things...

Trends

It seems like the tide is turning towards single language solutions, as opposed to the old wisdom of using different languages for the client, server, scripts etc.

To make this work smoothly, we'll need language innovation. This has to be a good rhing, right?

that's weird

From the current trend, i'd say this "single language solution" looks more like "different specific languages all embedded and integrated into one", like javascript+html+more with Links and C#+SQL with LINQ.

If this turns out messy and hard, i don't believe it'll be much better than lots of little language sections separately developed, hopefully by specialists in their respective areas... it's really annoying when programmers need to be (crappy) webdesigners because the web UI is scattered among lots of "reusable components" and files...

haXe

Yes I agree with this. Taking a language such as Java that hasn't been designed with "targeting different runtimes" in mind might not work very well. For instance if you want to bind a simple JS "onclick" event, how can you do since there is neither local functions nor method rebinding in Java ? You need to modelize all you API with the infamous listeners and wrap the native API accordingly.

As for the "single language", I think it makes sense for the Web. I would say that currently people are experimenting a lot with "one language for several runtimes" with the opposite of "one runtime for several languages". The main reason is that language designers see that in its current state Javascript have a lot of drawbacks that need to be fixed by using a more highlevel strongly-typed language.

haXe is bringing its own solutions, especially for communications between JS/Flash/Server (see http://haxe.org/tutos/remoting for a Tutorial on haXe Remoting).

Its's not typical do assign

Its's not typical do assign event listeners directly in JS nowadays anyway. It's more typical to use addEventListener(), attachEvent(), or some bit of code that wraps around them and detaches them on page unload to avoid memory leaks.

So while I'm quite weary of GWT, that's not an aspect it can be criticised upon.

I don't think it was 'wisdom'

Meaning I don't think anyone was advocating the benefits of developing in different langauges on client and server. All these technologies appeared at the same time and the lowly app developer was stuck with the job of making things work.

As web-based apps get more complex, and context-switching between server langague,client language, html, xml, xslt, etc gets more expensive for the developer to process, simplifling things by eliminating the context switches seems like natural evolution.

I am not sure how much

I am not sure how much wisdom was involved, but there were many discussions about these issues (some more well informed than others), which influenced the ways people chose to do things.

one vs many

I don't mean to agree or disagree -- just explode this into more detail for thought.

Ehud Lamm: It seems like the tide is turning towards single language solutions, as opposed to the old wisdom of using different languages for the client, server, scripts etc.

It's like a single language solution for an initial simulation of a later deployment context that uses multiple languages. It seems very pragmatic as a way to avoid/remove the fragility of development directly in JavaScript. And simulating a system you target is a clever way to do things, though burdened with some up front costs (which folks usually hate with a passion).

But in a one vs many solution space, it seems more a move to many than a move to one, when you see the use of Java as a (temporary) substitute for JavaScript before deployment in JavaScript. If in the long run this was just a move to displace JavaScript with Java, yeah, that would be more a one language solution.

The flavor of Google's tactic (using Java to for development time debugging) resembles my notion to develop in an easier, very dynamic language (Lisp, Smalltalk, and/or Python) before deploying in whatever the runtime context demands when I apply code to some application delivery context.

I'm just not real excited about the use of Java for this, since Java reminds me of the verbosity of C++, which is a drag. But Java is an extremely practical choice given current tools, and given desire to see some adoption by folks out there trained now, as they are.

I'm glad Google is doing this, since it makes using a sequence of languages in development sound less crazy to folks who otherwise assume this can't work (and then offer little but flak). I wish more folks would get with the program, and learn everything you target is a machine you can design another layer on top of, to wrangle some control over your attempts to develop for the machine.

Ehud Lamm: To make this work smoothly, we'll need language innovation. This has to be a good rhing, right?

Yes, I think so. If nothing else, something in the web toolkit would reify some of the model of the whole machine involving JavaScript, web pages, and servers, etc. Not only would these stakes in the ground be useful, but the higher order manipulations of this reified system would be a welcome change to random chaos in development. (Does "random chaos" sound negative? Probably. :-)

I don't think anyone but Google would try this; I expect it has something to do with their reputation for hiring folks with higher educations, and thus with a tolerance for abstractions and plans, which are very much frowned upon in the industry today. Modeling anything at all is a big extravagance most places, where they don't even want you to write plain english notes on how your code works, because anything but code appears a frivolous waste of time.

Language innovation requires something for the innovation to target; so now we might get some if some higher order way of expressing how a system works might get some adoption. There might be some innovation in the way the web toolkit generates JavaScript. (There's needn't be, though. The translation could be written in a non-retargetable way with very opaque manner that brooks no interference, forking, or understanding. Depends on the goals of the toolkit maker.) [cf]

the use of Java as a

the use of Java as a (temporary) substitute for JavaScript before deployment in JavaScript

It seems to me JS is simply used in toolkits such as this as the "native" language of the target platform. The assembly language of the browser world, if you will. Amusingly enough the JVM was supposed to provide this portability layer, but beacuse of the way java applets work, the AJAX application model doesn't use java for client side programming.

The clue to look for in these situations is whether the generated code (in this case the JS code) is supposed to be directly maintainable (and readable) by people.

Trying it out

I've been working with it for the past few days, and I must say it's quite excellent. I don't really think any of the code it generates would be all that maintainable by humans, but the code I am writing in Java is a lot better organized than what I have written in JavaScript and the tools support is definitely making web development feel more maintainable overall. I'm a bit queasy about abdicating direct control of the source in the browser to a Google compiler. I've already thrown something at it that caused Firefox's JavaScript engine to freak out, but actually what I wrote was unecessarily complex automatic resizing on window resize because I wasn't understanding how to get what I wanted out of their dock panel. The benifits are so far outweighing my doubts about abandoning direct control over every line of scripting code in the browser. The real achievement for me is that they have managed to bring a decent component framework to the web. Existing JavaScript libraries are just that... libraries. It doesn't really feel like you're getting the kind of rich ready-made widgets that GWT gives you. The single-language approach also makes it extremely natural to implement RPC. You just define an interface for an object you wish to call remotely and write an asynchronous sibling interface, and GWT automatically creates an implementation of the asynchronous interface based on the original on the client side. You point it at a URL of the implementor of this interface and (as far as the abstraction they lay out is concerned) you're sending Java objects across the wire. It's very smooth. Anyway, thank god I'm over Ruby. Despite the Rails hype, I think Java is going to be an effective language for web development for some time to come. You just can't judge the entire language and community by the uncritically-adopted J2EE frameworks put out there by major vendors. Stuff coming out of Apache and Codehaus really impresses me. I think a lot of people who read LtU are pretty down on Java and rightfully so, considering it isn't exactly breaking massive theoretical ground. When working on research software in it I hated it a lot, but now that I'm writing web / business code, I'm starting to come around. Definitely less fun than Scheme and OCaml, but it's such a luxury to have selection when it comes to off-the-shelf tools. Java has a good community going for it. I recommend checking out Google's addition to it.

Thanks for the experience

Thanks for the experience report!

Did anyone else try it out?

Sample output fragment

function a(){return window;}
function b(){return this.c + '@' + this.d();}
function e(f){return this === f;}
function g(){return h(this);}
function i(){}
_ = i.prototype = {};_.j = b;_.k = e;_.d = g;_.toString = function(){return this.j();};_.c = 'java.lang.Object';_.l = 0;function m(n){return n?n.c:null;}
function o(){return $moduleName;}
p = null;function q(){return ++r;}
function s(t){return t != null?(t.$H?t.$H:(t.$H = q())):0;}
function u(v){return v != null?(v.$H?v.$H:(v.$H = q())):0;}
r = 0;function w(){w = a;x = y('[N',[0],[0],[0],null);return window;}
function z(){return this.A;}
function B(){var C,D;C = m(this);D = this.E();if(D !== null) {return C + ': ' + D;}else {return C;}}
function F(ab){w();return ab;}
function bb(cb,db){w();cb.A = db;return cb;}
function eb(fb,gb,hb){w();fb.ib = hb;fb.A = gb;return fb;}
function jb(){}
_ = jb.prototype = new i();_.E = z;_.j = B;_.c = 'java.lang.Throwable';_.l = 1;_.ib = null;_.A = null;function kb(lb){F(lb);return lb;}
function mb(nb,ob){bb(nb,ob);return nb;}
function pb(qb,rb,sb){eb(qb,rb,sb);return qb;}
function tb(){}
_ = tb.prototype = new jb();_.c = 'java.lang.Exception';_.l = 2;function ub(vb,wb){mb(vb,wb);return vb;}
function xb(yb,zb,Ab){pb(yb,zb,Ab);return yb;}
function Bb(Cb){kb(Cb);return Cb;}

Hmm

That source code looks awfully familiar. Look through the Google Calendar source code and you'll see what I mean. For example:

http://www.google.com/calendar/20060518145122doozercompiled.js
(This link may become inactive very quickly.)

I hadn't heard that Google used this framework to build it; I wonder if that's true?

(Edit:) On second thought, it's probably just the short variable names due to it being compiled. I don't see any instances of "_.prototype".

Script#

Looks like the .NET camp is trying out something similar with Script#. I find the wide range of responses to Nikhil's blog entry interesting.

In the C#-to-JavaScript case, I think the win comes from two things: the use of the Visual Studio IDE for development, and the use of the ASP.NET object/event model for the page. I can't say I'm convinced that C# is the best choice for coding this kind of thing (I feel the same way about Java), but I think leveraging an existing server-side code model, as Script# does, is potentially very powerful.

The Google PC?

GWT (the google web toolkit) is probably part of the strategy for the google pc (if there is one).

Boutin notes that Vic Gundotra would be anyone's first pick to persuade software makers to build Web-based programs to Google's specs. While this may be true, it is not the whole story. The real clue is that you need developer tools, and if google is spending energy and money on developer tools it suggests that the google pc is proablby more than just a rumor. Microsoft is, of course, basing a large part of its stategy around C# and the .Net framework; Sun has Java. Google's task seems harder since the programming model required for modern web applications is more complicated.

We will keep monitoring how this story develops and see if my predications turn out to be true.

js vs java

If we switch from JavaScript to Java, we gain tool support: static type checking, auto-completion, refactoring, debugging etc. But what do we lose?

We lose free-standing functions. For example, I have a function at(array,indices) that returns another array. In Java, I have to put it in some class - and no, I can't put it in Array, because Array in Java isn't even a class.

We lose closures. I have a function map(func,array) that returns another array. Now I need to put in some class (syntax inconvenience for all users), and func needs to become a functor object. What should the functor object return? Object? Hint hint: in my code, it sometimes doesn't return anything. Just use "return null"? Semantic inconvenience for all users.

We lose some useful argument-passing conventions. For example, I have a

function bind(f,x) { return function(y,z) { return f(x,y,z); }; }

This kind of code is tricky to translate to Java, because f can take 1, 2 or 3 arguments. In JavaScript, it just works.

We lose useful collections. The JavaScript array has [] syntax and is auto-resizing; Java doesn't have this. The JavaScript associative array has [] syntax and dot syntax; it can be used to implement explicit namespaces, objects and what you will. Java doesn't have this. Instead we get tons of collection classes; but I have never needed a custom collection class in JavaScript, the two built-in ones were always enough.

We lose prototypes.

We lose eval.

In short, we lose all higher-order programming and all metaprogramming. Is the switch worth it?

That's why...

That's why you can use haXe instead.
You get :

  • a static type system
  • first class functions
  • closures
  • optional arguments
  • type inference
  • mixed OO/ML style type system
  • structural subtyping
  • iterators

looks nice, thanks

I'll try it when I get tired of JavaScript :-)

java to language x

Once i wrote a eclipse plugin to create ActionScript from Java, see osflash.org/j2as, runs on 3.1 only. My reasoning was to be able to use all the great java tooling in eclipse for my actionscript work. But in the end i stopped working on it because of two reasons:
1. It's very hard for a Javaprogrammer who doesn't know ActionScript, to create the appropriate code.
2. When you need to debug the code, you are debugging actionscript, and not java. This makes it very hard to see from which line in your java code a problem comes from.