Lambda the Ultimate

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

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

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

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

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

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 report!

Did anyone else try it out?

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;}

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

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

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