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?"
Because a big company open sources something we're supposed drop what we're doing and run to the next best thing?
JavaScript libraries and toolkits multiply faster than rabbits, there's a new "framework" coming out each week, and some of them had strong developer support (i.e. people willing to answer my stupid questions in forums) long before Google came out with their stuff.
Not that it's bad or anything, but in the end it's all JavaScript anyway, and learning two different ways to get to the same goal (an interactive site) is generally pretty low on everybody's priority list.
Are you using Google Sparse Hash by the way? Why not?
is that everyone wants to roll their own.
How we know is more important than what we know.
To me, the biggest problem is abolutely no fallback to non-javascript browsers. I'm not so much worried about users, but search engine bots won't be able to spider me and drive traffic to me.
-Bucky
...just not as much as you might expect. Part of the issue is that it's designed for when you develop your application from scratch. Generally with the intent of developing a desktop replacement webapp. The only problem is that not many companies are investing in such apps. They're investing in using DHTML/AJAX to make their sites more interactive rather than replacing the HTML interface outright. In that situation, GWT is not the ideal solution. (e.g. For quite a while, you couldn't even have more than one widget per page!) It works though, so you'll find it pop up here and there.
On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.
Javascript + Nintendo DSi = DSiCade
We built a Proof of Concept Report Designer and Report Viewer on top of BIRT using GWT for the interface. It had some cool features, like multi-user real-time report development, versioning, and tie ins to the commercial report repository that the company that built BIRT sells. It had a real nice WOW factor to it, but in the end, it was just a pretty POC that we could show at conferences, it would never replace the desktop version due to responsiveness (imagine, an Eclipse app that is more responsive than something else...) IMHO, web technology is just catching up in the UI space to where desktop apps were like 15 years ago, and Web 2.0 is still a tacky buzzword. To do some things that are trivial in a desktop app requires a lot of convoluted steps (callbacks, etc). And even things that would be done the same way still requires a network round trip to get information that desktop apps don't suffer (simple tasks like dynamic drop-down or list population). GWT is a step in the right direction, and the ability to debug in an IDE both client and server side components is very nice.
I'm a long time web developer but I've never even cracked open the box on GWT, so take this with a grain of salt.
The idea of depending on generated javascript scares me. I'm against writing Javascript in Java, Ruby, Python or anything else. Javascript is just too much of a beast to debug to leave everything up to an opaque framework, and I want to be able to get my hands dirty. I like the smaller and more traditional open-source style frameworks. Prototype, jQuery, MooTools, even Dojo just scare me a lot less.
It could be totally irrational, and it also could be the fact that I tend to build web applications that need minimal state and pretty basic AJAX interactions. Nothing anywhere near as dense as, say, Gmail. If the right project came along I'd definitely give it a more serious look.
There's a lot of corporative GWT-apps because it's, probably, the best toolkit for rich-client web applications.
However, it's not used much in the public web because most sites just don't need that kind of user interfaces.
Also, GWT is incompatible with web spiders.
I spent a month using it to build something in April 2007, and it was a big ol' pain. Getting something that roughly worked wasn't too bad, but there were a number of bugs and quirks that cost me time and headache.
Also, their rendering components generated an awful lot of hard to manage HTML and CSS. There were several display issues I never got quite right, and when I asked a front-end whiz to help me out, he had some very unkind things to say about the generated code.
My end impression was that it was about 0.7 in quality, needed a lot of polishing, and was really only useful for Java people who didn't want to understand what was actually going on in the browser. Were I to do that project over again, I'd instead just use something like JQuery, and learn how to do JavaScript properly, rather than hoping a framework would save me from my ignorance.
Probably the most popular social website in Lithuania uses GWT - www.one.lt.
My biggest problem is that I'm studying frameworks, JITs, libraries, languages and spinoff languages nearly constantly, and they're multiplying faster than I can even say I've given a look at them.
Just a few weeks ago, I had an itch to scratch, so I figured I'd bang out a quick fix in my most well known language, Java (I started Java around early 1.4 days back in high school, as they were fading out C++, although I passed the AP test in C++ the last year it was given in that language). I figured I'd expand my horizons a bit and learn Java Enterprise, as I already have a really solid background in Standard Edition. After compiling a JBoss server, Ant, and getting JBoss studio (read: a day later), I decided to jump right in. Several hours later and a trip to the book store later, I realized that I needed more background info and got the hardcopy version of the Java EE Tutorial. It assumes that you know, XML, RPC, SQL, Hibernate, ODBC, etc. I've got experience with a good deal of it, and it's still a daunting task to learn just the architecture of the Java EE suite. This is before even thinking about writing a bit of code. The amount of time that you have to invest and the steepness of the learning curve is, frankly, intimidating!
My Eclipse install is a gigabyte, ATM, I've got about 10 IDEs, 3 SQL servers, and a directory called 'programming' with a range of tools and a sub directory called 'libraries' which has SDKs that I've downloaded and intend to getting around to trying. I bought Flex2 and Expression Studio last summer and have barely had time to play with them, and both have new versions out already. Then I've the SDK for Android, Flex (looks like another month of studying the architecture just to hit the ground running), and AIR, all sitting around for me to have time to play with them, before they're obsolete. Not to mention another Java release in the wings.
There are simply too many frameworks, languages, and methods for anyone to be well versed in more than a small number of them. And they come and go so quickly, I don't know if I should invest time in what might become the next Laszlo (looked really, really, cool - never got any traction). Google offers APIs and SDKs in what, half a dozen languages, and half of them are just interfaces to XML? What's wrong with libcurl?
I've only got so much time, and lately everything falls in to one of three categories, "cool, and worth the time investment", "cool, but probably only for my own hacking around", and "...what the crap does it do?".
Am I the only one with this issue? I admit, I spend a lot of time playing with Linux distros, too, so I have less time than others. Oh, yeah, and the four or five languages I'm expected to use every semester, and the three or four that I use at work on a monthly basis.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
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
Because most web developers don't know Java. They know XHTML, CSS and Javascript. Some know PHP. Most sure as hell don't understand how Java can be used to make a site and don't want to bother learning a whole new "language" (as it seems) to build one. So they dely on jQuery and Dojo which is pure Javascript that they understand.
I've been on a project using GWT in 2007, been quite successful. If you want to see an example that is public run over to Parlays.com, they have a Flex and a GWT version.
If you want to write clean code check out my blog on TDD with GWT: http://is.gd/1156.
With the 1.5 release they did some very promising improvements.
So you're right if you say it is not mainstream, but to say nobody is using it is exaggerating. Just be patient, GWT will continue to grow.
Show a man some news, distract him for an hour. Show a man some mod points, distract him for the rest of his life.
We have used it for a fairly big internal application for one of our clients. Given we wanted ajax rather than a typical rich client, the main advantage of GWT was that we could program in the same language end-to-end.
We managed to avoid a lot of boilerplate code by using the same data class definitions (POJO's) in the server and client. So an object might be created by hibernate from a database record, copied to the client, displayed and edited, copied back to the server, manipulated there and finally updated in the database via hibernate.
The main omission in GWT is a good framework for binding data to UI elements. Because there is no introspection available in the GWT client environment, it is hard to do this in a generic way. We solved the basic problem by generating class and property descriptors during the usual hibernate code generation step. We then created a UI-POJO binding framework that picks up and uses these descriptors. Again avoiding a lot of boilerplate.
Our code for all this is here: http://code.google.com/p/gwt-hibernate/
I'd say GWT worked out pretty well.
You start with the assumption it should be widespread, and are disappointed because it is not. Which leads to the question, what leads you to that assumption?
You must beone of the REAL PROGRAMMERS one keeps hearing about who do not use compilers...
Apart from a few niche Web 2.0 sites, most websites are still built using tried and tested backend tech, and laid out using HTML, CSS and some graphics. GWT is pretty much doing everything using Javascript and a little bit on the server side serving xml/json. Not everyone needs AJAX. Most sites need to be able to work without it (for accessibility, backwards cinpatibility and non-javascript visitors), so unless its capable of adding really useful features (cases of which are few and far between) AJAX and GWT are just not necessary. Its nice if you can have it, but its a luxury you don't actually require for a usable website / web application.
Caesar si viveret, ad remum dareris.
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.
Because I needed a website with a high level of interaction. The client asked for enabling disabling of various things on a widget, some bells and whistles,but nothing fancy. In the beginning I wrote the code for this using javascript, hand coded the whole thing. But change requests, and much more important than that, browser compatibility problems cost me a lot of time. GWT fixed this aspect. Mostly compatible with all major browsers, and being much more experienced in Java than in js, I became more productive.
However, I should have limited my implementation to a single widget, and that was my mistake when using GWT. Use a plain jsp page, attach the widget to a div, and be done with it. Instead I've built the whole thing on GWT, and later fell in a position where I can not easily add very simple stuff. The usual GWT app is one single js chunk, which navigates to different pages by hiding and showing things on a page. This requires a little getting used to, and I've implemented more flexible things like pulling html via remote calls etc. But in general, mixing GWT with a more server side oriented technology (asp.net, jsp, jsf etc...) looks like a better approach now. But when you have to build a slightly complex interface where there are trees, enabled disable compoenents, users adding, removing things to a list etc, GWT serves well. I guess the secret is in the balance, just use it at the necessary level, no more. I could have used Flash, but that'd be a total pain for multiple reasons. (a lot of reasons actually)
http://en.wikipedia.org/wiki/Progressive_Enhancement
When building sites I start with the plain HTML, make it usable, and then use statically linked JavaScript to start rewriting the page with the bells and whistles when the page loads. That way, if JS is not enabled the reader doesn't get the 'enhancements' but the core functionality is still there.
Stupid flounders!
As has been previously stated, there are multiple solutions to an ever-changing problem - rich internet applications inside the browser - but I think Google have come up with a clever solution in GWT, not just as a front-end UI framework but also in terms of a solution to scalability, maintainability and deployment.
To make anything work in a real environment, a GWT front-end is going to have to talk to a back-end somewhere. If Java really is your thing, you get RPC talking to Tomcat out of the box, or in my case I chose a REST solution. As a tool to complement your other frameworks, GWT never gets in your way, allows you to work at the DOM level where necessary, and fits in well alongside other 3rd party solutions.
Mozilla have their solution with XUL although you are stuck inside Gecko, and who knows what is going on with Microsoft and XAML, and of course there is Flash with its install base. However, with GWT, Google are producing cross-browser compatible output across all major browsers and they picked Java to do that. Using an established language does have benefits (existing frameworks/expertise/unit testing/debugging) but it is how they use that language that makes it clever.
http://riflethru.com/ is an interface for searching eBay that I developed using GWT, as is the iPhone version. When first picking up the toolkit, the article I had read stated "they have taken HTML, Javascript and CSS and turned it into byte-code", and upon further inspection, it turned out to be true. In my experience, GWT is versatile, capable and on the march.
The web is reaching everywhere so a solid HTML solution like theirs sits well in different environments and devices, but Java is certainly not for everyone. My guess is that this has little to do with the limited adoption, of which GWT does not appear to be suffering as a result. In addition, the publicity from Google I/O will fuel the fire, no doubt, and I see the YouTube figures on their presentations are numbering in the 1000's, although I had to watch Deferred Binding 3 times myself.
Theoretically...
Number of Java developers > Number of Flash developers > Number of Silverlight developers
Number of Javascript capable browsers > Number of Flash enabled browsers > Number of Silverlight enabled browsers.
Which is a good idea, since Google has created a framework in a language that most developers are familiar with, for a platform that just about all web browsers support out of the box.
However...
Number of PHP hosting sites > Number of ASP hosting sites > Number of Ruby hosting sites > Number of Tomcat hosting sites
Which is probably one of the reasons why it's not doing so well.
GWT-RPC is excellent. It allows me to use the same data objects on client and server, and debug both from the same IDE. But it requires a Tomcat server.
Now if GWT is able to compile the server portion to easily deployable PHP code, this could lead to somewhere interesting.
Getting complex client side JS working well on different browsers is difficult. If GWT Java => JS compiler can take care of that automatically, it will save TONS of effort.
--Coder
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!
We did a QA interface to one of our projects so we could test the backend without going through the rich client. It was a great experience and really easy to get working. The javascript/java backend communication was ultra-simple to get working.
But...
If we want to really easily create something that looks great we'll be sticking with more traditional approaches either using Flash/Flex or AJax with a standard JS library. Having a designer skin a GWT app is harder than those approaches.
I've been reading a lot about DWR and that plus a UI library will probably give you most of the benefits of GWT. Have to give it a try soon.
It doesn't have any of the good widgets that exist on most of the google pages that make them great, at least the last time I looked. For instance, there's no pop-up calendar date picker like Google Calendar uses. There's no form field completion popup with scrollbar. So if you want to do anything good, you have to roll your own anyway, or use something like YUI.
If you are going to end up using YUI anyway, it does everything GWT does and more, so you might as well simplify and limit your third party library complexity to one fewer library.
Also, when something doesn't work in GWT, you usually end up debugging the javascript anyway. It's a lot easier to navigate code you wrote than generated code.
It really doesn't buy you much over JS-only toolkits, IMHO. Unless all you know is Java and you want to make a very very simple website.
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 think the market has shifted a bit more than you're giving it credit for.
But it all depends on your niche.
We built our business on web retail and we still do an awful lot of it. And in that world, you simply cannot afford to lose a customer due to whatever whizbang technology you want to use at the moment.
But outside of retail is very different.
And the truth is, non-JS visitors and non-Flash visitors are the slimmest of minorities. 1-3% on average. If I was targeting the /. market I'd accommodate it. But for a general cross-section of the web? Javascript rules the day.
>Not everyone needs AJAX.
To expand on this, not everyone needs Google's API to do AJAX. It's possible to write cross browser AJAX code and not end up with 10k of javascript. My own stuff ended up being 1.58k total.
This code reads xml (generated by server side processing on the fly), and generates large dynamic arrays of form controls, as well as the typical list population stuff. In my case, that's all I needed.
It will actually _add_ to a user's experience if they are on a slow modem, since the static html would be 100k +. The AJAX powered stuff is under 8k source they are downloading.
If I used googles API it would take 2-3x as long for someone on a slow connection. Anyone that's seen the broadband penetration numbers for the U.S. (just hit 50% in April) realizes that page size is, indeed, still important.
Add that fact to the fact that you become dependent on google's site being up when you use google's API to generate your interfaces, and it's simply not an attractive option for some (apparently most) people.
It's Google's API so it doesn't suprise me that they are just about the only one's using it. AJAX is Really Simple(tm) stuff. You are better off grokking it and writing the minimum you need to do the job.
I do use google maps though; that's cool stuff. However since my site will work if the map server dies, I don't feel so cagey about using it.
-Viz
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
So you write all your software in binary?
How is writing in Java and compiling to JavaScript any different than writing in Java and compiling to bytecode?
There are some good reasons mentioned here, but I wanted to throw in my 2 cents as well. I have used Wicket professionally and loved it. I evaluated the GWT on my own time and was moderately impressed. HOWEVER:
Most people that are in charge of project are not going to pick a "new and cool" component-based web framework like the GWT or Wicket simply because they are afraid of what they do not know. I am not talking about some guy providing professional services (those are the people mostly using Wicket and GWT actually) but about primary architects at medium to large corporations with multi-million dollar budgets.
Why do they not make what I think is the right choice? The fear is part of it of course, but these guys are good, smart professionals, so there must be another reason. I believe that reason is the glut of web frameworks currently available on the Java platform. Even evaluating one takes time a lot of these people do not have. If they cannot evaluate everything, they cannot agree on anything, so there is no industry wide consensus. Most of these people are very careful risk-averse individuals (a good trait to have for an engineer), and there we are.
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...
* Keyboard support to Menus and TabBars
* Added ARIA roles/states to MenuBar/MenuItem, Tree/TreeItem, TabBar/TabPanel, CustomButton/ToggleButton/PushButton
* Screen readers are now able to identify and speak the content of these widgets
* Improved tab navigation
* New API to set ARIA roles/states on Elements (still experimental)
We used the GWT to build the GoGrid control panel. As we just got slashdotted today, Slashdot | EC2 Vs AppEngine Vs GoGrid Vs AppNexus, I think that makes us a big site using GWT.