Is Anyone Using the Google Web Toolkit? 470
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?"
To me, (Score:5, Interesting)
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.
It's used... (Score:3, Interesting)
...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.
Seems Too Heavy (Score:5, Interesting)
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 are GWT apps, but not in the public web (Score:4, Interesting)
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.
Re:To me, (Score:5, Interesting)
My (possibly stale) impression (Score:3, Interesting)
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 [jquery.com], and learn how to do JavaScript properly, rather than hoping a framework would save me from my ignorance.
Re:To me, (Score:3, Interesting)
> tech-savvy
It's likely that the MOST tech-savvy are the ones disabling javascript. The novices haven't even heard of it, leave alone be familiar with its particular annoyances, and have it enabled by default.
I block flash for 99.8% of all web sites, only enabling it on a case by case basis with the FF extension. If a site doesn't work without javascript, I usually just don't go there. This (and adblock) makes the web remarkably less annoying.
Because web developers don't know Java (Score:2, Interesting)
Not being used?? (Score:5, Interesting)
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.
Re:It's used... (Score:3, Interesting)
The ideal solution in that case is NOT frameworks. It's to have runtime patches available that make your code run predictably on all browsers. That way if you need to support a new browser, you just add a new patch so that it functions predictably. (If necessary.) Since such patches tend to function based on whether or not a particular feature exists rather than the browser itself, they automatically deactivate when the browser maker finally gets it right.
In practice, of course, things are not nearly as bad as they're made out to be. IE needs the most patching for issues like DOM2 Events (or lack thereof), but otherwise coding to the base standards means portable code across browsers. No significant part of the industry is really doing anything fancy like SVG, Canvas, or Local Storage. (Yet, anyway.) The simple loop of "event fired, contact server, get response, update DOM" is actually pretty straightforward. Especially in the circumstances where GWT fails.
Meanwhile, I've seen all manner of screwy problems caused by folks who try to plugin a framework. One of my favorites was an issue with the prototype library where it was incorrectly deleting the "display" value to make an element visible. Obviously the hope was that it would display as a block element by default. Let's just say that it didn't always work right.
The reason why that example is my favorite is that it's such a stupid little thing. All that was needed was a simple "document.getElementById("myelement").style.display = 'block';" and you're done. There was no reason to abstract that. The abstraction actually CAUSED cross-browser issues rather than solving them. Not a good design.
We are (Score:5, Interesting)
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.
Re:It's used... (Score:3, Interesting)
You write a runtime patch once and you're done. Meanwhile, you upgrade your Prototype and Scriptalicious libs and then spend an ungodly amount of time troubleshooting incompatibilities between versions.
Sounds like a winning proposition to me. ;-)
Frameworks are almost most often more trouble than they are worth. Once you understand Javascript, you realize how stupidly simple most of the tasks are, and how much time you've been wasting on the framework. If you don't understand Javascript, you probably have wasted dozens (if not hundred!) of hours fighting with issues that are actually very avoidable to begin with.
e.g. Most folks don't understand Javascript scoping. So they'll be surprised when they accidently change a variable that they're using elsewhere in the code. A very simple mistake to avoid if you've read the documentation [mozilla.org]. But as Douglas Crockford of JSON fame has pointed out, most programmers start trying to hack the language without first understanding it. Which is a huge mistake considering that Javascript is only superficially similar to C/C++/Java-type languages.
Obligatory plugs of my own apps (Score:4, Interesting)
Re:The secret shame of Web 2.0 (Score:5, Interesting)
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:To me, (Score:1, Interesting)
Web browsers aren't the only things which download web pages. Web crawlers such as google, yahoo, and msn also download your pages. These crawlers wont ever render a page. They only strip out searchable content. If someone isn't careful about non-visual text (alt-texts and such) it is possible to get a very low search engine ranking for an otherwise excellent site. The same is true for javascript (read: ajax) generated content.
Personally, I think this scenario is rare. But it is a valid concern.
No, it isn't rare. I currently work as a SEO. What does that mean? I spend 80% of my working time in fixing these things. People who have not made headings as H1, H2, etc. with proper markup and CSS but have rather went the SPAN+CSS (or even FONT) route because if they don't know about search engine algorithms, they see no advantage in marking documents with H1+CSS or SPAN+CSS - it looks the same!
(Remember, folks. Page is not valid just because it passes validator. It also should be semantically done)
Other things I constantly need to fix include:
Naturally there is more to SEO (Site structures, flow of link juice, controlling indexing with robots.txt and sitemaps, a few more blackhat things that aren't really used often, etc.) but most of my work is fixing things that the webmaster should have properly in the first place.
And it isn't just small companies. Large companies that have e-stores that themselves give much more profit a month than I could hope to get in a year and even large, international companies... All seem to have similar problems.
Re:As a Software Development student (Score:3, Interesting)
Sorry, just have to ask: What do you recommend instead of jsf? This comes from a guy who has to choose a java web stack for an upcoming project, that'll have to scale. No need for a flame war, just asking for a short answer here :)
Re:Why are you expecting this? (Score:5, Interesting)
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:As a Software Development student (Score:4, Interesting)
What I was trying to get at is that, I've mostly mastered the concepts, and now I want to try everything that I can. Almost everything that I do is for the challenge/thrill of it. Yet, at the same time, I desire that what I hack around with should become a tool in my toolbox. It's almost like writing code that never gets used; it just feels wrong to pour your blood, sweat and tears in to a project that never gets used.
I guess it's in my blood, my great grandfather was an architect on the Hoover Dam and Chrysler building, my grandfather a civil engineer (apparently, he used to slam trains together in White Sands, NM. with explosives on them to see how much shock would set them off), and my uncle owns a software company. It's like I have to find the biggest, baddest problem that I can, and then I must own it! And not just own it, but own it from three angles at once. Then, I put it down and almost never pick it up again unless someone asks me how I would attack that problem. I intern for a small local company where I maintain a Linux server, an old Access database, and write some bash scripts... and play with new 'shiny objects' when I've completely my assigned work. (my boss is a Comp. Sci. geek from back in the day - I can usually get him to let me geek out with stuff since he enjoys it as well, and on occasion, it's worked out well for the company) But when I get home, I want to build something! The more elaborate, the better!
With SDKs, it's the same thing. I'm fairly sure that between kernel hacking and the release of java.util.concurrent with Java 6, (or maybe they extended it...) I failed a course or two. To be honest, while immature, I'd probably say it was worth it for the hours of fun it provided to fully grok the Java threading model or the interrupt routing for an SMP kernel during a critical section of code. The icing on the cake was when I got to hack around more the next semester while we were covering those topics. Or being able to speak somewhat intelligently on the use of 'goto' in class after reading about it in Code Complete. Sure, the extra pay off is nice, but it's what I would have been doing regardless.
Maybe I'm sick, but I love programming languages. Last semester I was required to do a bit of LISP and PROLOG for AI class, ADA95 for procedural languages, and took up PERL for fun. They're all really fun to hack around in (except I can't really find a great use for PROLOG), and I'm always on the lookout for a chance to break out ADA again. Take it as you will, I also enjoy using recursion. It's too elegant to not admire.
So, for mine own part, I've found that solving problems is relatively simple, just break it down in to atomic sub-problems, start with the most trivial, and divide and conquer each layer above it; if the solution makes sense, it works. I just want a few more hammers to try out on other problems. Unfortunately, mot problems dictate the most correct hammer by the time you've broken them down to isolated cases, and usually the most boring hammer is the one you should employ.
Re:fr0sty piss (Score:5, Interesting)
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.
I used it (Score:5, Interesting)
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)
GWT is more evolved, solving multiple problems (Score:2, Interesting)
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/ [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.
Re:There are GWT apps, but not in the public web (Score:3, Interesting)
There's a lot of corporative GWT-apps because it's, probably, the best toolkit for rich-client web applications.
There's also Java Applets.
Admittedly never got the popularity Sun originally hoped for, but if you want filthy rich clients, Java applets can do that for you.
GWT is a good concept (Score:5, Interesting)
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.
Re:Why are you expecting this? (Score:5, Interesting)
D'oh. I'm a Googler but seriously, nobody is meant to understand compiled JavaScript. Good thing then, that GWT provides a mode in which it does not minify the code, so if something does go wrong in the generated JS you can track it down in the human readable version.
There are a lot of GWT myths floating around here. I don't work on it but I did adopt it for a project of mine recently, and it's worked out pretty well so far. Myths I saw reading this thread, in no particular order:
I suspect you'll see GWT used more and more in future. It's such a radically different approach it takes some getting used to, and whilst it does support evolving an existing codebase towards it, it's still easier if you start from scratch. Still, I do believe that GWT is one of the nicest open source things Google has released for a long time. It's very well thought out and is designed to be very efficient, which is important for any non-trivial web app.
Internal project (Score:4, Interesting)
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.
Re:Why are you expecting this? (Score:3, Interesting)
No good widgets (Score:3, Interesting)
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.
Re:There are GWT apps, but not in the public web (Score:0, Interesting)
Re:The secret shame of Web 2.0 (Score:3, Interesting)
I've noticed the same thing.
I'm a partner in a mid-sized software dev firm. We're a job shop that is slowly bringing our own product to market.
Anyhoo, we wrote a route costing app for a certain airline (hint: It wasn't a foreign airline) about 5 years ago and we've upgraded the app about once a year since.
Last year we were asked how much it would cost to re-write as a web app.
It's not a broad app in terms if its function. But it's got a set of algorithms that are very tightly wound and the best guess of my web guys is that writing it in an interpreted language would slow it down considerably. (We're primarily a Python, PHP & Ruby shop when it comes to web dev.)
I told them and asked them why they were unhappy with the current Citrix nFuse (or wevertf it's called this year) deployment.
They weren't, they told me.
Long story shorter, they just wanted a web-style UI.
And they wanted it bad. So bad, that we re-worked every screen in the application.
We made it look like web browser.
There's an address bar, screens can be book-marked, back and forward buttons, all buttons in the app have been re-styled to hide the button border and put a blue underline on the button text. Etc Etc Etc.
Luckily it's not MDI or we'd have been creating a tab interface :)
honestly, that re-design probably cost $25,000.
No functionality was added. Just a different UI.
And this is why i think "cry me a river" whenever airline CEO's are crying to congress about not being able to stay afloat.
Re:General rule of thumb (Score:3, Interesting)
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?
Re: Accessibility :Why are you expecting this? (Score:4, Interesting)
* 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)
Re:To me, (Score:3, Interesting)
Perhaps, sense I already knew everyone was going to make that argument, you should realize that none of you have thought this though from a business perspective.
If I was a reseller to businesses I probably would not have a store front. I would have salesmen that I would send out. So bulk purchases are not a issue. Secondly, how many disabled people are going to buy my product as gifts? Is that profit greater then the cost of building a handicap accessible walkway to my business? If I make one handicap modification, I've opened the door to lawsuits if I do not cater to every handicap need. So now I have to take in that cost.
The bottom line is it should be MY decision on which customers I wish to target, not the government. So lets take this to a crazy extreme. If I owned a bar and did not want to serve blacks, that should be my right. Sure it is racist, but that should be my right. I own the property, I should choose how it is run. Now I personally would not go to a racist bar, but I would not begrudge the right.
Here is another example, my county has banned smoking in bars. How is that their right? As a non-smoker, I choose to go to non-smoking restaurants and stay out of bars for that reason (I don't like smoke.) However, I feel it is NOT my right to tell people who bought property and pay taxes that they must restrict a legal action on their property. Simply because it inconveniences some people (non-smokers) to go there. IF the non-smokers were such a market, they they would be catered to. Obviously they are not a market or there would be smoke free bars without laws being made.
I guess I'm saying let the free market do what it does best. Forcing the hand of business is a bad thing.