Google Web Toolkit
GWT is the Google Web
Toolkit.
It consists of a Java-to-Javascript compiler, cross-browser AJAX GUI library, and a self-hosting tool for Java source-level debugging using your favorite IDE.
- Java To Javascript
- Java2Script is another Java-to-Javascript technology but is fully
Open Source and uses the SWT GUI API.
- Compiling to Javascript
- http://calculist.blogspot.com/2006/08/compiling-to-javascript.html
- Scheme to Javascript
- http://hop.inria.fr/usr/local/share/hop/weblets/home/articles/scheme2js/article.html#SCM2JS-Compiler
Commentary
I am firmly convinced that application programmers should not code to device-specific (or even deployment-specific, call me quixiotic) APIs.
GWT is more appropriate for companies which have sufficiently large user bases (read budgets) and requirements unmet by device-independent toolkits to justify new GUI library development.
Of course, client-server-only solutions (DWR, Echo2, WebCream, etc) give up standalone (which includes disconnected client-server operation) deployments. Also they have server-side resource requirements that are impractical for massive user bases. Of course massive user bases are rare and Java enterprise companies are used to committing huge per-user resources which they can do because they have puny needs that will never pass 100K concurrent users and most have numbers in the 1000s or less.
I don't think GWT will give up anything to DWR or Echo2. I don't see anything particularly compelling on their side. I agree with Bruce Johnson that GWT's architecture is the path to no-compromise AJAX.
OTOH, GWT is not yet ready for prime time and is going to need additional layers and tools to be a really good solution for typical Java enterprise client-server applications. I think the most pragmatic GWT practice for Java enterprise companies who just gotta have it now is probably through JSF or Spring MVC.
Drew Kutcharian wrote:
> Why is there so much hype about GWT in the community and no
one
> really talks about Echo2. I think Echo2 is a LOT more advanced
and
> mature and is more in line with Java Server Side development.
Is GWT
> popular because of Google branding or am I missing
something?
GWT is significant because it enables no-compromise AJAX performance while being able to write client-side code in (pseudo) Java.
Approaches like Echo2 and DWR (and my AppletServer and CreamTec's WebCream) relegate Java code to the server-side. That means client-server roundtrip overhead and will never meet the no-compromise target of GWT (which aims to be used in things like Google Maps and GMail). These approaches *are* suitable for many typical Java enterprise applications.
The Google brand gives folks confidence in this new-fangled and complex technology. Without that, uptake would be much (much!) slower, just look at Java2Script, which preceded GWT's initial release by quite a few months.
GWT (at least at the application developer level) is not suitable for most of those companies. So the bad thing about the Google hype aspect of GWT is that many companies are adopting it who probably shouldn't (although I do recommend it over any approach that involves having your Java application developers write Javascript).
Articles
Good interview of Michael Podrazik by Tim O'Brien
Exploring GWT by Philip McCarthy on IBM
developerWorks
"In this interview with Artima, Scott Blum, the Google software
engineer behind GWT's Java-to-JavaScript compiler, talks about the
challenges of turning Java source code into JavaScript." :
Compiling Java to JavaScript, A Conversation with
Scott Blum.
"Google's Bosworth: Why AJAX Failed (Then
Succeeded)"
Resources
gwtDeveloper is a GWT designer for JDeveloper: http://www.gdevelop.com/
Josh Rehman wrote:
> Last but not least this redo has got me thinking: why did Google release GWT?
A brief and pithy answer is here:
http://code.google.com/webtoolkit/faq.html#why
My theory (confirmed by a Google VP) is that the experience of developing Google Maps, GMail, and other AJAX applications has led to an intense to desire to find a better way because the techniques they've been using are obviously a lousy way to live, and GWT aims to be that better way.
Bruce Johnson (GWT Tech Lead) leads off this talk about GWT with that very rationale:
http://googlewebtoolkit.blogspot.com/2006/11/gwt-tech-talk.html
So GWT is an answer to Google's AJAX development needs. They Open Source it because that is a better, faster, cheaper way to get the high quality results they're after.
GWT is not an answer to the search problem. In fact the Java RPC style that they advocate is an anti-pattern for web search. RESTful design is the right approach for client-server interaction on the web, and it enables things like search to work well.
Google is hardly a monolith, and so there is no surprise that not everything is perfectly rational. I'm sure there are also AJAX folks in Google who have no interest in using GWT, and more yet that await proof of its effectiveness.
Googling around to find those links led me to this interesting bit:
http://code.google.com/webtoolkit/makinggwtbetter.html#roadmap
The other significant Java-based AJAX toolkits I was trying to recall are:
TIBCO General Interface
This is an amazing toolset that nobody knew about because it wasn't OSS. It has an excellent GUI builder in GI itself. The whole thing, including the builder, is BSD now.
http://www.tibco.com/devnet/gi/
Be sure to check out the video presentations. Be sure to see the mapper demonstration. Rather than focus on low-level RPC, they are web standards-oriented and do WSDL (not that SOAP is very good, but at least it has standardized metadata) and XML Schema (of course RDF Schema is better ;-) with GUI point-and-click. Click on "screencast" in this blog entry about the GI 3.2 release:
This is an article on using GI with Spring:
http://ajax.sys-con.com/read/253549.htm
ICEfaces (from ICEsoft) is now OSS:
OpenLaszlo
OpenLaszlo now has AJAX (and is getting Dojo components) in addition to Flash client support. Originally developed by IBM, it has many significant deployments.
OL has the best approach (they call it LZX) for packaging reusable Javascript components (if you aren't using Java-to-Javascript that is).
http://www.openlaszlo.org/lps/docs/guide/comp-intro.html
The thing I like about LZX is that it could easily incorporate Java scripts as well as Javascript and would be a nicer way of integrating native Javascript than GWT's JSNI.
http://weblog.openlaszlo.org/archives/2006/02/class-based-oop-in-javascript-done-right/
DWR
A significant difference with DWR from the others is that DWR only works for client-server deployments.
J2S (Java2Script)
J2S actually came out before GWT. It does a Good Thing by not introducing YAWT (Yet Another Widget Toolkit). Instead it implements SWT in AJAX. This will (eventually) enable Eclipse RCP applications to be easily deployed as AJAX applications: