Slashdot Mirror
Is Anyone Using the Google Web Toolkit?
eldavojohn writes "After seeing some applications from Google and participating in the Google Codejam (which seems to be built using the GWT), I kind of expected to see websites spring up left and right based off the GWT. Well, it's been a year and a half since they open sourced it and I have to admit that I am more than a little disappointed by its low profile in the UI community. I've been trolling their blog and have seen a few books out on it. But the one thing I'm not seeing is its use outside of Google. I've worked through the examples and tutorials at home and though I've been impressed with the speed, I am disturbed by the actual result — a whole ton of generated Javascript. But this is the first UI technology I've found where I can write in the native language of the server (Java) to generate and unit-test the UI code. Aside from Google's use and the games of Ryan Dewsbury like KDice & GPokr, does anyone know of major sites using the GWT? If you don't and you've used it yourself, why isn't it taking off? Is it too immature? Is it a solution to a problem that already has too many solutions? Is it fundamentally lacking in some way?"
Probably the most popular social website in Lithuania uses GWT - www.one.lt.
My experience with GWT is rapid prototyping. Overall, I like playing around with GWT. It's a great way to quickly dynamic web sites without wading through the mess that JavaScript is. Considering that I do other kinds of software on a day-to-day basis; GWT has a learning curve that's gentle enough to allow me to write powerful UIs as a weekend project.
GWT's integration with Eclipse; especially its debugger, is a significant advantage. Its compiler is also another advantage. I tend to shy away from JavaScript because I prefer compiled environments with rich debuggers.
I think GWT's long-term strengths could be its maintainability, although someone who is experienced with both JavaScript and GWT will be better off making such a judgment. I have not written a large, multi-developer GWT application; thus I do not know what kind of complexities arise in such an environment.
GWT has an odd deployment system that's designed to take advantage of HTTP caching. Compiled javascript files are named based on a hashing algorithm, thus a web server can be optimized to instruct the browser to only download code when a new version is compiled. This makes storage of compiled JavaScript difficult for some deployment scenarios, because the files always change.
I've been reading the mailing list for about a year, and in general, it tends to have a lot of novices and hard-core Java developers. There's a lot of talk about using various Java frameworks within GWT. I get the impression that, even though GWT is Java-based, using frameworks like Spring or Hibernate is like ramming a square peg down a round hole.
Some novices don't understand that GWT doesn't run under the JRE, or assume that GWT can somehow magically make their favorite library run in the browser. GWT compiles Java into JavaScript; it does not deal with Java bytecode (except in its debugger.)
There's also a lot of talk about using various RPC / Remoting protocols when served from a Java web server. It seems that some Java programmers like that they can keep a simple layer between code running in the browser and code on the server. I personally avoid these layers and stick with simple AJAX calls into PHP or my custom-written C# server.
I wrote this in GWT as a learning exercise: http://andrewrondeau.com/com.Memmexx.GearPod/GearPod.html
Now, you might think "wouldn't it be a cool idea to integrate an MP3 search engine into your demo?" I did, but it's locked behind closed doors because I don't want to get sued! (It turns out that the folks at Seeqpod got sued after I completed the version with the search engine.
No, I will not work for your startup
Here's a hint for you: Use Glassfish. Your life will be about 1000x easier.
Here's another hint: No matter what anyone tells you, AVOID JAVA SERVER FACES LIKE THE PLAGUE. The API will not help you.
Hope that helps. :-)
Javascript + Nintendo DSi = DSiCade
you probably do not know what 'valid' means in this context...
When people are looking for an Ajax toolkit, the Google name often gets it onto the selection "short list", but that doesn't automatically assure that it will be the final choice. Many corporate IT organizations insist upon commercial support for any software that goes into their business-critical applications. Of course, Google does not provide such support. In those situations, GTK will be ruled out for business reasons, independent of its technical merits. The net result is that there are numerous sites built on GTK, but the large variety of choices means that no single framework or toolkit has yet emerged as a favorite.
I've recently spent a year with the GWT, and just a couple of months with Flex.
I would use Flex to flashify whatever dynamic parts of a standard html page I needed to for my next project. Everything that I'm trying to do in GWT could be done much faster in Flex... and when you are done in Flex, you are really done.
In the GWT, you have to be aware of what html each of the Java GWT widgets equates to... and then in the CSS, you have to work thinking about the resulting html. (FireBug makes it pretty easy.)
Cons for GWT 1.4:
- Long start-up times: web sites can take 8 seconds to show you their first page as the GWT javascript initializes.
- One imperfect CSS declaration, and you're having to debug IE6 / IE7 / Firefox / Safrai issues... Only very plain sites are insulated well from browser incompatibilities.
- Your site is all-or-nothing GWT. It's possible to use one GWT app to automate one part of a static page easily... but usually your whole site is 100% GWT, with no other static pages outside of the GWT's control.
- The AJAX mechanism on RFC-compliant browsers only lets you make two async requests at once... a third request is queued until one of the first two async requests returns... making it only asynchronous to an extent.
- I ended up having lots of html in my .java files, and using the HTMLPanel to turn that html into a GWT Widget. There are some parts of a web site that really do make more sense as HTML, and there's no easy way in GWT to keep the html separate (no templates!?!)
- The integration of GWT development can be done simply, but it can also grow to mirror the complexity of EJB style Java junk way too easily.
- IE needs special treatment (worth repeating.)
That said, it's probably the best way to create a web app for an iPhone right now, since there's no flash on the iPhone. (Please Adobe, I'd love it if you created an Air run-time for the iPhone!)
Pros of the GWT:
- it makes it easy to handle the back button and bookmarks.
- it can scale up to fairly large sites, and the smallest building blocks can be kept clean and small.
- the end user experience is a good one after that start-up delay.
- The GWT team has done lots of fantastic work, and in an open exchange... one of my coworkers has committed some changes to one of the supporting libraries.
Flex, on the other hand is designed to appeal to people who are weary from fighting CSS / browser incompatibility issues. In Flex, you still use CSS, but it works the way you would expect all the time. In Flex, you can also skin any compononent to look however you want, and then have a very clean top-level which wires up the various components with their skins. It's really beautiful... and best of all, when you're done, You're done! You don't even have to test on IE6! The learning curve is about the same, or a little harder, but it's all forward motion.
My next site is going to be 80% Django templates, with a good dose of mochikit (or dojo) for some dynamic parts, and a few Flex / flash applets sprinkled in where they make sense.
Celebrate Excellence!
All the templates are done in HTML and code is in Java. Can't get any simpler than that.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
I ultimately scrapped this project and started it over using another google product, Google App Engine. All client side stuff is done using jQuery, it gave me an excuse to learn python which I absolutely love. And, GAE has the specific goal of making it easy to deploy and scale the application, which was always something I had dreaded even thinking of.
Similes are like metaphors
I've used GWT to develop a pretty sophisticated server-side piece of a vertical market product. I approached GWT with much of the same trepidation as you have expressed. In the end I just had to "let go" and think of Javascript as an assembly language. (After all, I've been ignoring assembly language all these years, why not ignore Javascript?)
Now that our product is in a mature phase, and looking back at what we've built, I'm amazed by the brilliant design tradeoffs chosen by the GWT team at Google. Kudos.
The generated Javascript ended up being very easy to debug, and exceedingly lightweight. Since the source language is static, the compiler is able to leave out every feature that you didn't use. Their "Pay As You Go" philosophy actually works.
The only major caveat that comes to mind is that GWT shines for "web apps" more than for "web sites", which may account for why the submitter isn't seeing GWT "in the wild". It's important for sites to be spiderable, and you get the most leverage out of GWT when you're building an all-in-one-page DHTML rich-client application, not a site. It's still useful for sites, but then you'd be hunting squirrels with a bazooka.
But that can be fun, too.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...