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?"

Why are you expecting this?

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?

Re:Why are you expecting this?

The wacky Javascript that GWT generates is fine if your a Googler and understand and can fix issues that might occur but there many other cleaner solutions out there that mere, non kool-aid drinking, mortals can much more effectively work with.

Re:Why are you expecting this?

GWT is NOT a Javascript library! It's a Java library and a Java-to-Javascript compiler; it saves you from having to learn or work with Javascript at all. This means that you write your client in Java, same as your server-side code, and get to use a real Java debugger.

The secret shame of Web 2.0

is that everyone wants to roll their own.

Re:The secret shame of Web 2.0

Mostly because no one's really gotten it right yet.

That, and we still don't have any set of frameworks which have built up enough to be difficult to replace. Nothing close to, say, GTK+, Qt, WinForms, Cocoa, etc.

Re:The secret shame of Web 2.0

No, the cool, unique properties of a web app are pretty much entirely the user experience -- the fact that there's nothing to download, and no updates to manage.

I develop a rich client application for internal corporate use, and I find that casual users really miss web-style navigation. I get a lot of requests that are essentially requests to simulate a web experience by providing a bunch of screens that users can click through to find the information they want, instead of using traditional (perhaps formerly traditional?) GUI ways of exposing functionality.

Also, these days, mashups and Greasemonkey scripts really magnify the value of web applications. Deprecating a web application in a big company can be nearly impossible because you find out that there are a bunch of business processes that depend on mashups and fancy Greasemonkey scripts that have been hacked together (usually by interns, IT guys, and other random people) and that provide substantial business value.

Re:The secret shame of Web 2.0

The secret shame of Web 2.0^W^W^W^W programming in general

Fixed that for you.

Re:The secret shame of Web 2.0

Aha, gotcha! I knew someone would pedant all over me no matter how many "^W"s I put in there. You'll be happy (or possibly appalled) to know that I actually opened up a gvim window, pasted my text in there, and hit control-W, counting the presses till I got the desired result. First one kills "0", second kills ".", third kills "2", fourth kills "Web ".

Too bad Slashdot doesn't allow the <strike> tag, which I would prefer.

You may now pelt me with taunts of "NERRRD!!".

To me,

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.

Re:To me,

Exactly. Man, when I finally decided to really get down and dirty with HTML (translation: when I decide to learn all aspects of HTML and its related technologies), I got all hardcore over XHTML and CSS. I spent more time validating my site to strict XHTML than making the site prettier (not to mention producing better content). After a few years of my addiction to usability and valid forward-and-backwards-compatible code and Jeffrey Zeldman articles, I finally realized that I was wasting my time. Users don't want valid code: they just want pretty, moving pictures and sound (that they can easily turn on and off, of course).

Re:To me,

It's not about valid code, it's about accessibility.

Your attitude is the same as some dick opening a shop with spiral stairs leading up to it 'cos it's prettier, right?' Yeah, except for those wheelchair users.

There not be many disabled people compared to 'able', but if you ever become disabled one day, you'll be shouting from the roof for more accessibility just like all the rest.

Re:To me,

How do you get to the roof in a wheel chair?

Re:To me,

you probably do not know what 'valid' means in this context...

We had a POC Report Designer

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.

Seems Too Heavy

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.

one fairly large website that uses GWT

Probably the most popular social website in Lithuania uses GWT - www.one.lt [www.one.lt].

I wrote this in GWT...

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 [andrewrondeau.com]

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.

Not being used??

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 [is.gd].

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.

We are

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/ [google.com]

I'd say GWT worked out pretty well.

So, where's the question?

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?

Re:It's used...

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.

It's not learning Javascript that's the big obstacle to coding your own solutions sans framework; it's dealing with the browser compatibility issues. Frameworks largely compensate for that.

If you write your own non-trivial Javascript code, you have to test on IE 6/7/8, FF 2/3, Opera 9.whatever, Safari 2/3, etc etc etc etc.

Re:As a Software Development student

After compiling a JBoss server, Ant, and getting JBoss studio (read: a day later), I decided to jump right in.

Here's a hint for you: Use Glassfish [java.net]. 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. :-)

Re:As a Software Development student

As a student, don't bother learning frameworks with the idea that you will use them later. There are only two good reasons to learn a framework. The first is to use it right away on a project you want to get done. The second is to get experience with frameworks in general and particular types of frameworks. It is valuable to be able to:

• Learn a framework quickly.
• Understand the advantages and disadvantages of frameworks, as opposed to lightweight approaches.
• Evaluate and compare frameworks for a given task.

Knowing a framework is, in itself, pretty useless unless you are going to use it right away or apply for one of those mythical Monster.com jobs where companies hire people to work with version 2.37a of Ridiculously Specific Technology Z. I don't know of any companies that actually hire that way unless they need a consultant to work with a legacy system whose developers have long since disappeared. In other words, you won't be hired for your experience with a specific framework until that framework is obsolete.

Now, setting aside the proper way to study frameworks, why are you even thinking about frameworks as an "investment" at your age? You sound like you're in way too much of a hurry. If you learn one distributed N-tier application framework, one web application framework, and one rich client application framework, then you will have much more industrial-type experience than most developers ten years older than you. The downside is that industrial-type experience, while it helps you make better decisions about large-scale software development, also tends to dull your brain. If you're already focusing on frameworks in college, you're going to be burned out and useless by the time you're thirty. You'll end up quitting and starting over from scratch in a new career, just to get away from software. Unless you're just one of those precociously responsible (*cough* boring *cough* *cough*) kids who tracked his gas mileage in high school and thought the coolest thing about the Science Fair was having an excuse to wear a suit and gesture at graphs.

In college, you should be implementing your own language, becoming a whiz at Emacs Lisp, mucking with kernel modules, starting your own web business, building natural language parsers, and doing all the other silly, vain, perfectly useless (Emacs Lisp excluded) things that end up making you into a smart, versatile programmer.

Re:As a Software Development student

As a software development *student*, you should be focusing more on the concepts, on engineering problem solving, and on reasoning skills than on the specific technologies.

As a software engineering professional, I learn the tools that I need to effectively do my job. I learn things that look interesting and applicable to whatever it is I am doing. Thus, I work with the GWT and with AJAX because I decided that's what I needed in order to tackle a problem we were having. As a senior engineer who is engaged in the hiring process, I care more about that you can think than that you happen to have seen and worked with twelve dozen technologies by the time you graduated. As a job posting I saw recently says [fogcreek.com]:

We do not hire based on a specific list of buzzwords, technologies, or popular acronyms on your resume. Today we happen to use Wasabi, JavaScript, xhtml and CSS, and C++ to build FogBugz, but Python and .NET are likely to be important in the future. We use C++ and Objective C for Copilot. We have server systems in C# and legacy code in VBScript. Tomorrow we may be using something different. Whatever technologies, languages, or development environments you've been using, we expect you have mastered them in depth, and we expect that you will be able to master any technology, language, or development environment that we need in the future.

You can't predict it and the specific tools will change tomorrow, so as a student I would generally say that learning it--unless it is for a specific project or class of projects, or because it contains a concept or problem solving idea that you want to learn--is a waste of time. I learned R back in school because it was more efficient than using Minitab for multivariate statistics and for statistical modeling, not because it was out there and I needed to put it on my resume. On the latter point, I still think learning Prolog and LISP were extremely valuable despite that I never use them professionally and will probably never use them professionally.

Incidentally, if you are a good engineer, the language doesn't matter. If you are a bad engineer, the language still doesn't matter. *Problem solving* counts for more in the long run than bullet points.

Re:fr0sty piss

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.