Summary
Today Google announced the release of its Google Web Toolkit, or GWT, under the Apache License. A crucial piece of GWT is a Java-to-JavaScript compiler that allows the development of rich-client Ajax applications entirely in Java by compiling Java code into highly optimized, browser-specific JavaScript.
Advertisement
Initially launched in May of this year, the Google Web Toolkit, or GWT, has quickly become a popular option for building Ajax-style Web applications. While parts of GWT have always been available under an open-source license, today Google announced that it released GWT RC 1.3 under the Apache License. Future GWT versions will also be released under that license.
GWT is unique among rich-client development tools in that it allows coding applications targeted for deployment in browsers entirely in Java. A crucial piece of GWT is a Java-to-JavaScript compiler that performs static analysis of Java code, generating browser-specific JavaScript that performs equivalent operations.
Last month, Bret Taylor, senior product manager for Google developer tools, explained to Artima readers that GWT produces highly optimized JavaScript, in keeping with Google's obsession with fast download:
We concentrate a lot on optimizing performance, even for very low-end browsers. When we compile, there are a number of different JavaScript and HTML files as output. Depending on your browser and platform, you might [load] a different file. We've done that so that we can have the absolute minimum code size for every single browser configuration.
The GWT will do static analysis of the code, and remove all methods that you don't actually call. We do very aggressive static analysis so that if you import a huge Java library, and only use one class, and one method within that class, we eliminate all the other code, and won't output [that] to the JavaScript.
We take advantage of strong types in Java to do this. With a more dynamic language, it would be quite difficult, if not impossible. Obviously, there are more dynamic features in Java, but for the vast majority of GWT applications, the reason the applications can come out compact and so efficient is because we take advantage of very aggressive static analysis.
According to Taylor, GWT takes the approach of considering JavaScript effectively an assembly language for the Web:
The Google Web Toolkit, or GWT, at core is a Java-to-JavaScript compiler. It lets you develop your Ajax application entirely in Java, debug it entirely in Java, and then you can compile that Java application into browser-compatible JavaScript and HTML that runs in any Web browser.
It's amusing to think of JavaScript as an assembly language, but in practice there are so many idiosyncrasies with all the modern browsers, that it's a valuable tool to have a cross-compiler. Just to give you an example, when we launched Google Maps in February 2005, it only worked in Firefox and Internet Explorer, and not in Opera and Safari. The reason was that the sophisticated UI programming we were doing in JavaScript was very different in Safari and Opera. So significantly different that it took us about a month or two to add Safari and Opera support. With GWT, you could write this once, and with no special cases in your code get it to work in all browsers. It's probably not all that big of a difference for small applications, but once your application grows in size and complexity, it's a significant time-saver.
GWT also comes with a rich widget set, a hosted browser that facilitates debugging, as well as a full RPC protocol to facilitate communication between browser and a special RPC endpoint servlet. Client-server communication is also highly optimized.
What do you think of GWT's approach of treating JavaScript as a kind of assembly language?
It's obvious that we have always needed this kind of thing. The horrible blunder was to think that since all the browsers run JavaScript, trying to write a harmonising language on top of that JavaScript would be overkill.
In reality, these browsers almost run different languages. That's to say that the differences are so huge when you get to the subtle (and that's the important) details, that it's as different as C and C++, at the very least.
This is perhaps the strangest piece of software I've ever heard of. The only other thing that comes to mind is COBOL++.
Here's how it got to that point (extremely condensed version)
A decade or so ago someone comes up with a tag language to put some pages on the web and there were smiles all around.
Then someone else thinks hey wouldn't it be neat to be able to change the tags on the fly so that we can turn bold on and off. Dynamic HTML is born.
Then the DOM comes along and DOM scripting is the rage.
Then the web browser is too slow so we come up with Ajax which is really client server by another name.
Then Ajax is too complex so we decide to write it in Java and cross compile from Java to Javascript.
The tower of babel springs to mind.
Has everyone lost sight of what's trying to be achieved here? We want to display some database records on a screen using http as the transport protocol and be able to update them.
Maybe I'm a grumpy old engineer but when I put together my first PC nearly thirty years ago if someone told me this would be floated as a really good thing I would have backed away quietly. How many person years has been wasted on this? Surely there are better things to develop? Isn't this reaching a point of diminishing returns? I might take up kite building.
> Then Ajax is too complex so we decide to write it in Java > and cross compile from Java to Javascript.
Not because Ajax were too complex. The point is that you can - develop in Java and use well-known Java tools (even the debugger) - forget browser incompatibilities and differences (which exist for well-known historical and political reasons)
> The tower of babel springs to mind.
Quite the contrary. The tower is hidden from the programmer by GWT.
> Has everyone lost sight of what's trying to be achieved > here? We want to display some database records on a screen > using http as the transport protocol and be able to update > them.
The browser is a stateless thin client that was not made to update records in a database. But it's possible and GWT shows how to do it in a convenient way.
But here you're defending putting a semi transparent wall in front of the tower of babel and blithely carrying on. The two viewpoints don't gel in my mind.
In my way of thinking it's time to move on from the browser as a universal client, the costs and complexity it is causing in the name of 'standards' is untenable. As a friend of mine says 'the great thing about standards is there's so many to choose from.'
> you're saying adding generics to > java is too complex, and yet this has a sound theoretical > foundation.
I don't see the connection between Java Generics and GWT. I'm all for simplicity in programming.
> But here you're defending putting a semi transparent wall > in front of the tower of babel and blithely carrying on. > The two viewpoints don't gel in my mind.
GWT seems to be more a transparent interface than a "semi transparent wall". We all probably don't know enough yet to make definitive judgments. Bruce Johnson gives some insight into the concepts behind GWT (both sources have transscripts; you need to launch the presentation in order to access the transscript):
> In my way of thinking it's time to move on from the > browser as a universal client, the costs and complexity it > is causing in the name of 'standards' is untenable. As a > friend of mine says 'the great thing about standards is > there's so many to choose from.'
I beg to differ. The browser is the most successful software of the last 10 years. In recent years we have also seen progress towards better standardization with each new browser release (even with IE).
> > > In my way of thinking it's time to move on from the > > browser as a universal client, the costs and complexity > it > > is causing in the name of 'standards' is untenable. As > a > > friend of mine says 'the great thing about standards is > > there's so many to choose from.' > > I beg to differ. The browser is the most successful > software of the last 10 years. In recent years we have > also seen progress towards better standardization with > each new browser release (even with IE).
I think what Dave is getting at is the fact that, as a platform, the browser is extremely limited in its capabilities. We are forced to retrofit out applications to an extremely limited programming interface, and an equally limited comm. protocol (HTTP). This, simplicity was perhaps the reason for its initial, resounding success, but nevertheless, it doesn't change the fact that we are nowhere near the full potential of internet based applications. Despite all the hype about AJAX, and despite all the really cool stuff that Google has done with it, the browser remains a fundamentally restrictive platform.
Java applets were an early attempt to overcome these limitations, and to provide a safe, sandboxed environment for delivering diverse applications. Unfortunately, the technology was the right idea at the wrong time (i.e. The bandwidth, VM and APIs were not developed enough at the time).
It would be just great if the browser could provide us a platform neutral and sandboxed environment for doing just about anything, from 3D gfx to windowed applications to whatever else one can imagine.
On a brighter note, Microsoft seems to have entered the fray recently with XAML browser applications and WPF/E. Perhaps we'll see some interesting stuff soon...
Very succinctly put, that is my problem with the continuing piling on of layers in the browser, trying to make it do something it was never built to do, each layer making it harder and harder to write a bug free application, and even to figure out why on earth that bug happens. It's not meant to be this hard.
A better platform is needed and perhaps as you say it will come soon, Flex is another one I've been looking at which seems interesting. My feeling is that many approach the browser as the ultimate platform, and this is the best thing that can ever be, particularly new developers entering the industry. When really it is kludge upon kludge, with this the latest in a long line of kludges, that seems even stranger than usual. Calling the kludge a standard doesn't make it right.
> My feeling is that many approach the > browser as the ultimate platform, and this is the best > thing that can ever be, particularly new developers > entering the industry. When really it is kludge upon > kludge, with this the latest in a long line of kludges, > that seems even stranger than usual. Calling the kludge a > standard doesn't make it right.
Couldn't agree with you more.
Even something as simple as drawing a pixel on screen is something that is not doable in a browser. Need to generate a simple pie chart? - generate it on the server and ship it over to the client. The comparatively infinite resources on the client lie idle while the servers struggle to "scale out". This is hardly an ideal situation...
I still feel sorry about the unfortunate demise of applets. It offered a tantalizing glimpse of what might have been... Oh well...
It is nice though, that stuff like Java Web Start and Microsoft ClickOnce do provide a platform for launching more "capable" apps over the Internet, and may well be the dominant way to deliver applications in the future. Do you see these taking off in a really big way anytime soon?
> Even something as simple as drawing a pixel on screen is > something that is not doable in a browser. Need to > generate a simple pie chart? - generate it on the server > and ship it over to the client. The comparatively infinite > resources on the client lie idle while the servers > struggle to "scale out". This is hardly an ideal > situation...
I agree totally, you could of course use SVG and write a couple of hundred characters to display a square :-(
> I still feel sorry about the unfortunate demise of > applets. It offered a tantalizing glimpse of what might > have been... Oh well... > I thought activex likewise was a useful technology. What would probably be good would be a library that supported a 2d and 3d graphics interface and some sort of installation / sandbox technology. For the 2d you could use Qt perhaps and for 3d OpenGL. Now that the mac is running on intel this would be easier - no endian problems. Then of course you get into problems like font rendering, Qt doesn't seem to be as crisp as Windows or mac for fonts from what I've seen, I could be wrong though. It would also have to be language neutral so that everyone would use it.
None of these problems are insurmountable, and are not really technical anymore, just political (therefore out of scope :-)). Upon reflection it probably wouldn't be that hard to build something like this. A web based multi-platform API - wouldn't that be cool (Google are you listening?), I think that we'll end up with something like this, it's just a matter of time.
> It is nice though, that stuff like Java Web Start and > Microsoft ClickOnce do provide a platform for launching > more "capable" apps over the Internet, and may well be the > dominant way to deliver applications in the future. Do you > see these taking off in a really big way anytime soon?
I haven't had much to do with either of these I'm afraid so I can't really comment. I had a quick look and they seem to be delivery technologies with a sand box type environment. Undoubtedly these, or something like these would be the ultimate technical solution - who knows when though. These are both environment dependent, so the war will go on I imagine :-)
Previous Topic
