Home

Technometria: Google Web Toolkit

Phil Windley Technometria podcast is dedicated to the Google Web Toolkit. The guest on the show is Bruce Johnson a Tech Lead of GWT.

The show is very good, and more technical than usual. Many themes that are near and dear to LtU are discussed. Here are some pointers:

Bruce talks at length about the advantages of compiling from Java to JS, many of which arise from Java's static typing. He mainly talks about optimizations, but also about how static typing helps with tools in general (IDEs etc.). This was a subject of long and stormy debates here in the past.

The advantages, from a software engineering standpoint, of building in Java vs. JS are discussed. This is directly related to the ongoing discusison here on the new programming-in-the-large features added to JS2. I wonder if someone will write a compiler from Java/GWT to JS2 at some point, which will enable projects to move to JS2 and jump ship on Java all together.

Bruce mentions that since JS isn't class-based, and thus doesn't directly support the OO style many people are used to, there are many ways of translating common OO idioms into JS. This is, of course, the same type of dilemma the Scheme community has about many high level features. Cast as a question on OOP support the questions becomes is it better to provide language constructs that allow various libraries to add OO support in different ways, or to provide language support for a specific style. The same can be asked about a variety of features and programming styles, of course.

Finally, Bruce mentions that as far as he knows no one thought about something like GWT before they did. Well, I for one, and I don't think I was the only one, talked many times (probably on LtU) about Javascript as a VM/assembly language of the browser, clearly thinking about JS as a target language. I admint I wasn't thinking aobut compiling Java... But then, I am not into writing Java, so why would I think about Java as the source language...

By Ehud Lamm at 2007-10-29 04:53 | Cross language runtimes | DSL | Implementation | Javascript | other blogs | 13144 reads

Comment viewing options

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

Declarative UI

The idea of adding support for declarative specification of UI elements is mentioned briefly. For related work see XSL and XAML .

By Ehud Lamm at Mon, 2007-10-29 05:38 | login or register to post comments

JS2

I am not sure how much JS2 follows adobes "action script 3" - but its optional typing is quite irritating. There seems to be no inference.

var m: Microphone = Microphone.getInstance();

is common code. Which is more verbose then java, definately a step backwards. Without the "Microphone" at the start, there is no knowledge of the type of m.

Any other strong statically typed language could benefit from this sort of cross compilation. I don't think it works well with dynamic languages (if you try, you end up having to write it in certain contrived styles, annotating things etc).

Scala would be a very interesting (and similar) source language for GWT (Haskell would be also fascinating, but no idea where to start with that one).

By michaelneale at Mon, 2007-10-29 06:18 | login or register to post comments

Scala would be a very

Scala would be a very interesting (and similar) source language for GWT


That's a cool idea!

By Ehud Lamm at Mon, 2007-10-29 06:23 | login or register to post comments

ASTs

Yeah - I would love it if the GWT concepts could be exposed to other statically typed languages - in terms of exposing the AST and populating it from other (similar) input forms. And then the benefits of the rest of the tool chain apply.

But time will tell. I guess this would have to come from outside of google, as for their own purposes (and the popular use cases) java as input is enough (plus combined with some layout template languages).

Stop looking at me !

By michaelneale at Mon, 2007-10-29 06:31 | login or register to post comments

GWT is open source... I

GWT is open source... I guess for it would be up to the Scala guys to do such a port. Maybe they should sponsornit as a Google Summer of Code project.

By Ehud Lamm at Mon, 2007-10-29 06:38 | login or register to post comments

Decompile bytecode?

I'm probably missing something, but I don't really see the problem: Scala compiles to bytecode. Using a decompiler (like Jad), this bytecode can be converted to Java code (of any version you specify, IIRC). Can't this decompiled Java code be fed to GWT?

Edit: thought about this a bit more. I forgot GWT can't use "normal" Java code, it only uses a subset of it, and has its own libraries.
Still, since Scala can use Java libraries, it can use GWT's, I would think. Then there's still the problem of Scala's bytecode probably using Java features which aren't in GWT's Java subset, but maybe this is a problem that can be worked around - either by adapting Scala's compiler, or by translating some of that decompiled Java to something GWT accepts (if it's only a couple of features which get used a lot by Scala), or by adapting the decompiler, or by enlarging the subset of Java which GWT supports.

By LudoA at Sat, 2007-11-03 13:52 | login or register to post comments

Scala / GWT

A previous discussion on the Scala mailing list:

How about a scala implementation of GWT?

Another thread:

Scala & browser side scripting

By Jeff Nowakowski at Mon, 2007-10-29 15:41 | login or register to post comments

Thanks for the links. My

Thanks for the links. My conclusion: They seemed more optimistic in 2006 than in 2007...

By Ehud Lamm at Mon, 2007-10-29 16:28 | login or register to post comments

Haskell -> Javascript

(Haskell would be also fascinating, but no idea where to start with that one).

Perhaps you could start with YCR2JS?

By JoshuaBall at Tue, 2007-10-30 17:33 | login or register to post comments

SML to javascript

Here it is: smltojs web site

By Gergely Buday at Fri, 2007-11-02 17:20 | login or register to post comments

The hard stuff

At Xamlon we converted IL (C#/VB, and a good chunk of the .net framework) into Actionscript bytecode (for flash) which was a very similar project. We often talked about also going 'from Java', and also going 'to JS' as it was such a small step. For the record this was pre-GWT, and I'm certain we were not the first either. Anyone who has tried to write a large application in JS has had this thought : ).

We created a whole type table system inside the flash vm, and in debug mode we could attach all kinds of usefule metadata to the types. We did get the benefits of a static compile, but probably only about 50% of the benefits of static code at debug time were reachable imo. Also, the fact that the source is one more layer of abstraction will be a problem for the end user in all of these transcoding systems.

The really hard parts were guaranteeing the order static ctors run (initialized in the order called - this would be easier in js with eval I think, which isn't available in AS), and ansyc calls/threads etc. The type stuff lines up really neatly with the prototype system, most code is similar, so that was all fairly straight forward. The other issue was scaling. A large .Net program would really need to push the Flash VM, as would a large Java program push the browser beyond the limits.

Our second incarnation, Aptana, was a JS ide. This is way harder to get useful information to the programmer, and impossible to do things like refactoring with any certainty. There is no way non-static languages can produce code that is as solid and scalable as static ones imo.

Interestingly people don't seem to be too concerned. The first product was somewhat of a struggle to get adoption (as is GWT I think), where Aptana is approaching 1 million downloads. I am certainly not bitter or anything, just really interested in why this is. I think in the end you don't really need the solidity of statically typed code until you reach a certain level of chaos with your style. For most people that is 1000 lines or so, others can go 10000, and some may never hit that. Most web stuff is of the less than 1000 loc variety, so JS works like a charm.

So now I'm starting to think scaling is overrated. Of course it is important when you need it, just maybe most projects don't need it. I'm not sure there anymore.

By debreuil at Mon, 2007-10-29 06:45 | login or register to post comments

scaling

So now I'm starting to think scaling is overrated. Of course it is important when you need it, just maybe most projects don't need it. I'm not sure there anymore.

I don't know either. Only been doing this for 10 years, still have a lot to learn.

By michaelneale at Mon, 2007-10-29 23:20 | login or register to post comments

I experimented a bit with

I experimented a bit with generating JS from Scala's internal bytecode form. Scala compiles to this internal form prior to generating bytecode for .NET or JVMs. This internal bytecode was at a pretty low level, so I ended up creating a small interpreter in JS for a bytecode-type language. The solution was quite unsatisfactory so I didn't proceed any further with it. Other possible approaches include compiling Scala to JVM bytecode, then _decompiling it_ (with a decompiler) back into recognizable Java source, then forward-compiling again with GWT -- all of which sounds quite roundabout.

Scala to Java is probably a nicer way to go, but you still have the same problem -- where in the compiler's phase chain do you do your work? Ideally it's as late as possible, but you need to go earlier in order to gain efficiency -- at least _some_ of the class structuring information needs to be available to generate better code for non-assemblyish targets.

By rossjudson at Mon, 2007-10-29 20:08 | login or register to post comments

compiling Scala to JVM

compiling Scala to JVM bytecode, then _decompiling it_ (with a decompiler) back into recognizable Java source, then forward-compiling again with GWT -- all of which sounds quite roundabout.


True, but doing this can be an amusing experiment...

By Ehud Lamm at Mon, 2007-10-29 20:29 | login or register to post comments

haXe

I actually already met Bruce in person, and I introduced haXe to him, which compiles to JS, Flash and NekoVM. He didn't know about it at this time, but haXe was released before GWT.

haXe is open source, has type inference and a lot of modern OO features (static duck typing, mixed OO/functional, ...)

By Nicolas Cannasse at Tue, 2007-10-30 16:11 | login or register to post comments