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.
It will be worth if we could cache the javascript unlike flash videos. Download once use many times. Save the bandwidth.
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 have used it for a transit/maps mashup application and it worked like a charm. I would agree with those who argue that it's great for writing new web-based apps from scratch and less for adding incremental dynamic features to largely static content sites.
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.
Personally, I was impressed with the toolkit and completely turned off by the use of Java. I'd much rather be programming in python, although admittedly it would make the most sense to use PHP.
Single page Ajax website = pain in the ass.
The premise of writing DHTML/Javascript and backend in one language (Java) and stuffing everything into one page sounds great, but creates complexity and headaches as the size of your project grows.
As a web programmer, you HAVE to learn HTML, proper layout, Javascript, server/client data format and some serverside language with data abstraction. My tools of choice is Blueprint, JQuery, JSON, and Perl/PHP/Ruby/Python.
If you really must have a rich client, I would suggest Flex over GWT.
This sounds kind of like ASP.NET development, minus the integrated IDE. Also, it's not particularly clear how to roll this out to my favorite hosted environment.
> 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
Wicket is all java, does Ajax very nicely and support unit test. It's component base with tons of contributed ones. Has a very active community and a very helpful mailing list.
There are more than 67 million businesses in the world and I wonder how many of those you have polled. Can you tell us how many of those businesses you have surveyed?
If you don't and you've used it yourself, why isn't it taking off? Is it too immature?
If you are asking a question and providing the answer, I wonder why you even ask.
In your submission, you should at least have informed us about Google's view on this issue is, if you wanted us to take you serious. Be serious please.
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
Of course it is... IT'S JAVA!
Jeremy Logan's Website.
GWT is too complex for the quick-and-dirty PHP weenies and too simple for everyone else (restricted libraries, no control over cron jobs, email config, etc.). It's like a VPS, but without all the hand-holding. (Disclaimer - this is my blunt gut feeling. Facts may be off)
To take the "anyone" in its strictest definition, yes, someone is using it. I'm working for a company that develops an opensource UI toolkit for Java, that takes heavy use of GWT.
OTOH, this is probably the only application outside of Google I, too, have seen using GWT.
I am convinced that I can always be convinced otherwise.
It fails my own general rule of thumb, which is simply that dynamic code generation is evil.
When you fully embrace this concept, it will take you far and avoid much pain.
There are no exceptions to this rule, other than things that give you simple templates that you then modify - but that's not really code generation so much as code thawing.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
If I remember correctly, this is the one where you write java and then it gets compiled into the javascript that runs in the browser, right? I'll admit that I'm biased against java, but still, even is this was my favourite language, the idea of generating javascript offline and then running it on the browser just sounds too complicated. I'd never feel like I could trust the generator.
I'm not saying it'll never work, just that I think this is why nobody is rushing to adopt it (I do think it's completely unnecesary, and it'd be kinda sad if this was what needed to be done to have a usable ajax framework; but that's just my uninformed opinion)
If this was a runtime thing, where you're running a virtual machine for some other language on top of javascript, I'd try it just because it sounds cool tho.
--
Stay tuned for some shock and awe coming right up after this messages!
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.
Becoming frustrated with basic and lacking on-line information, I had to peruse books to find better examples and explanations. I found only one GWT book at a Barnes & Noble. But Borders had several.
Also, I've heard that Eclipse isn't up to snuff with the GWT stuff. But as a `vi` guy, I'll keep my rat's ass and not give it.
The best i've seen is HectaresBC (http://www.hectaresbc.org/app/habc/HaBC.html).
It's an awesome way to query spatial data in a canadian state.
... than browsing with elinks? ... or with noscript?
http://www.whirled.com/ The non-flash components of Three Rings Design's new social networking/game portal site Whirled have been built using GWT.
We're going to be looking at it soon for an Intranet project, specifically ExtJS GWT. We'll see how it goes.
Yes, I am a smart ass; it's better than the alternative.
Mosso (http://www.mosso.com/) wrote the control panel for their cloud computing system using GWT and ExtJS.
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.
Theres some happy fapping to be had there, thx mate!
Redhat.com uses it for the store part of the site. Many other "of the shelf" type apps use it, probably not so much web 2.0 apps.
Slashdot
See subject.
It's not the desktops that lack of javascript leaves out, it's the non-desktop web browser. Like my phone.
So thank you for caring about no-javascript fallbacks.
GWT was originally marketed to web developers as a way to make developing web applications easier, since the underlying language is Java, which has better tool support (especially for debugging) when compared to plain old JavaScript.
A number of web developers interpreted this marketing spin to mean "convenient to program in but slow". This is not, however, the case. The GWT team has consistently favored the user experience (which includes performance as a large component) over developer convenience when the two goals were at odds. In general, the JavaScript generated by the GWT compiler is as efficient (and sometimes faster) than the code I write by hand.
So, in summary, I suspect GWT hasn't seen wider adoption by web developers because they think that it does not generate performant code.
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?
to develop this site ( and others ):
http://www.gochongo.com/
One big problem with using the GWT ( at this point in time ) to develop something like a media site is the failure to index.
One can be blacklisted in the search indices for presenting a site to a robot which fails to render properly. As 100% javacript sites always do.
At this point in time the GWT seems well suited for display of data and rapid prototyping and uses that have people coming to your site through means other than search engines. Or use it sparingly to augment your normal, indexable site.
I would be a complete fan if robots could deal with it, I really enjoy using it and can quickly make it do whatever I want and expect the output to render pretty much identically on all major browsers and be quite compact.
I forgot about it till just now. i know some girls who feel pretty used in the same circumstance...
I believe XWiki's WYSIWYG page editor is being rewritten using GWT.
Bostech Corp's ChainBuilder uses GWT in it's administrative console
Here's my suggestion: look for a simple string that occurs in GWT pages but in few other places, then Google for it. That should answer your question.
Just because there's not many GWT WebApps on the public Internet doesn't mean companies aren't using GWT behind corporate firewalls. The GWT forum is very active and there are postings from various big name companies there.
SpectaReg.com appears to use the GWT and was born from an intranet WebApp (i.e. runs on corporate networks). This enables System on Chip developers (like digital logic designers and embedded software engineers) to reduce costs and improve quality by automating addressable register interfaces. It's a pretty slick WebApp for generating code and documentation from single-source design specifications.
"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."
So if you use the tool Google recommends to create your website, Google won't index it properly and you will fall off Google rankings?!?
The problem with GWT is that it mixes so badly with other web toolkits. And it is not standardized, being neither fully Java nor JavaScript at all.
If you want to work in a class-oriented fashion for web development, you should probably go the way of JavaScript 2 as implemented by Jangaroo or Mascara. While JavaScript 2 is not finalized yet, we have a good idea of how it must be like from looking at ActionScript 3.
I used it back in Oct 2007 to develop an internal CDN monitor and control tool. It is used internally, and that project was used to see how well it worked.
Since then GWT 1.5 can come out, and it seems even better now. The reason it isn't used externally yet at my place it the "external" projects involve several developers, and they are too tied to the old ways (raw Java-script) to try something new.
(I honestly think part of it is, java-script is a maintenance nightmare, and thus "job security" for those people.)
I fully expect GWT to be used more, but it is being held back from "large" projects because not enough developers know it yet.
In a corporate environment you'll never get much traction for GWT.
Design agenicies deliver static HTML for their wireframes (with some Web 2.0 libraries sprinkled in). They have to else they'll be building the solution with GWT.
Evernote has a pretty slick web interface that is built with the Google Web Toolkit. I was positively surprised by its snappiness. Finding out it was GWT was sort of an "ah, but of course" experience.
parasight.de
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.
Er. Thats not the comment I meant to reply to ...
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.
We've been using it for about 18 months now to power our widget designer. One of the main advantages for me is the debugger, it's eclipse and you can just step through you client side code exactly like your server side code.
One of my colleagues wrote a review a while ago http://devblog.glowday.com/2007/05/tech-review-google-web-toolkit.html
I have a site developed using GWT up and running since almost two years. I have gone all the way from 1.2 => 1.3 => 1.4... Migrating between versions has not been flawless, but was less a pain than expected. Iâ(TM)m very happy with GWT, I would choose it again and fully recommend it for web development.
Check out: http://traceurl.com
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!
At my previous company I developed my own web framework for an AJAX app. At my current company, I used GWT instead and got many more features at far less cost, plus someone else is maintaining it. Adding new user interface elements in Java by extending GWT classes has been great for development.
That having been said, one of the biggest roles we use GWT for is to create the frame around a user-customizable user interface written almost entirely in pure Javascript. GWT handles the chrome, the RPC calls, and some other features, but what makes it work is that we can easily combine Javascript with GWT as we need to.
I use GWT heavily, but find the lack of models for the GUI elements the biggest problem, and the poor event model the next biggest. It's a bit like SWT in relation to Swing - it's easy to get something hacked out but eventually implementing new functionality becomes harder & harder. We've solved this by 'porting' the Swing APIs over to GWT. I built a TreeModel that allows for add/remove of TreeNodes and that fires TreeModelEvents. We wrap the GWT Tree (in a Composite) and register it as a TreeModelListener. Now we do all our work on the TreeModel, and let the GUI update itself. We've done the same port on the JTable/TableModel wrapping the GWT Grid. This takes GUI development one abstraction higher, making in conceptually harder, but long-term much easier. Google would be well advised to understand Swing and take GWT one abstraction-level higher.
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.
We're using it for this site: http://www.liveleader.com/. See the live demo if you want to have a look at an app built from scratch in GWT.
To me, the single biggest advantage of GWT is that I can use Java tools for development, refactoring and debugging. As a Java developer with limited JavaScript skills, that's a very big plus. And using Java all the way means that I can share code (and pass objects) between the client and the server.
The generated JavaScript is not very search engine friendly, but GWT apps can be popped into a regular HTML page. You should probably be using GWT for app-like stuff, not things you want Google to pick up.
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.
Its like watching a war in Lilliput. Meanwhile proper coders get on and write the serious back end stuff where you have to worry about query optimisations , memory usage, threading models etc. Not whether some fluffy widget is implemented using javascrap, ruby off the rails or some other mickey mouse sand boxed GUI enviroment.
ContactOffice is a collaborative and messaging platform offered in Software as a Service. ContactOffice's has recently rewritten its entire UI using Google Web Toolkit. In order to do so they had to add numerous features to GWT (drag and drop, marquee selection, contextual menus, sortable columns, resizable panels). It is according to Google engineers one of the largest and most advanced web application built using their framework. Joel Webber the co-founder of GWT endorsed the work done at CO at: http://blog.contactoffice.com/index.php/2008/01/03/nice-endorsement-for-contactoffice-by-gwt-team/. The CTO Luc Claes was invited by Google to present the work done at the last JAVAONE conference. You can also find some other GWT applications on the following site: http://www.ongwt.com/category/GWT-Application
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
Considering YUI is an actual javascript library (unlike GWT), is anyone using it? I've used a couple components of the library for a client, and have been pleased with the result.
Better known as 318230.
Whoever modded it troll should get their geek licence revoked.
Wikileaks, no DNS
I did not see many people in the thread giving some alternatives to GWT, well here it goes then:
This has its client written in java and lots of features:
http://echo.nextapp.com/site/
This one is pretty popular too:
http://www.zkoss.org/
GWT is a good framework, but not the best and that is why people are not using it too much... IMO.
It was about a year before and I did not check the new versions.
The flaws I would mention:
I made an inventory application with GWT. It is a simple catalog/SKU/invoice application for small businesses. However, I moved away from GWT for a couple of reasons. Their default serialization/rpc scheme did not work well with Hibernate (which has since been partly fixed), and drag and drop didn't make it into the standard toolkit for a very long time.
Just wanted to say that I read your non-hesitant reply to kdart about contributing back, and I'm really thankful that communities have people/companies that give back selflessly. Without everyone participating, the whole thing breaks down to some degree. Kudos.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
I know a large application by GWT and Google Gears. see http://wibokr.com/ a pretty good wiki system.
Agree with this. We're also building alot of internal web apps for corporate clients - it takes a little bit of effort but GWT can sit on top of existing Spring Services and take advantage of lots of deployed SOA, making the case for GWT very easy to make.
We also open sourced our code on google code, everything available here to have GWT/Spring/Hibernate/Maven2 up and running very quickly.
http://code.google.com/p/shine-reference/
In a word the strength of the web is the LACK of coupling between client and server tier. Tools like GWT cut against that. I don't WANT to have to particulars of the server side implementation all over the place on my client side.
I probably have different teams working on each portion of my web application. Why should I wish to have such tight coupling between them?
Furthermore in my 25 years of software development I've developed a real healthy contempt for automatic code generators. Nothing is more of a PITA than having to try to arm twist some code generator when it generates buggy code that doesn't do exactly what I want. It very quickly becomes more of a liability to the project than an advantage.
No, I would rather be able to develop client side logic built to the specification of the interface with the server side. Now, I'd be a lot more enthusiastic about having a GOOD GUI development tool for javascript/css/html/xml and a client side stub generator that simply wraps the SPECIFICATION of the interface between the client and the server.
Furthermore a GWT like system has all sorts of other architectural assumptions built into it that are likely to restrict the design of my system in various ways. Good tools ALLOW appropriate design, they don't railroad you into doing things a certain way. So, no, I am not particularly a fan of this approach and I doubt I will become one in the near future.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
We're building alot of internal web apps for corporate clients - it takes a little bit of effort but GWT can sit on top of existing Spring Services and take advantage of lots of deployed SOA, making the case for GWT very easy to make. Feedback over the last year has been very positive.
We open sourced a sample app to have GWT/Spring/Hibernate/Maven2 up and running very quickly, all details here.
http://code.google.com/p/shine-reference/
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!
My company is using it as an Administrative system to replace an aging Struts application.
We decided to use it only as an admin tool since we can control what browser is used and the requirements that are needed to use it.
Combined with Ext it's a great tool and we are finding it really effective in an alternative to a fat client.
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.
Can I just give a brief shout-out to k-Dice? It's a little buggy at times, but man, is it addictive and fun to play.
Random rants about technology: http://technorants.blogspot.com
We're considering it for http://www.BibleMaximum.com 's OneLine version to replace the UI framework.
So reasons it isn't used as much as it might be:
1. The pre-open source license was quite restrictive (i think it was non-commercial only)
2. Very few people are building full on rich client in a browser apps
3. html / css devs are a lot cheaper than java devs
Conversely I'm a java developer and I wrote the gui for http://www.bionicbooks.com (my site - an accounting app for small businesses) in gwt and it saved me a huge amount of time. Also the gwt forum is very active so there must actually be a lot of people out there using it. I absolutely love it and I'd highly recommend it.
Yeah, no integrated IDE available.
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
I tend to agree, I find that alot of the web apps out there create bloated code, and use too much fancy stuff, yet when you get an old browser on their page, oops, we cant serve you.
I created my own web site generator making templates out of php and asp.
I don't add javascript unless absolutely necessary like a calendar that pages through events
in real time, this you need actual jscript for, but the rest, you can just inlay pure xhtml, and off you go. No probs for lesser browsers.
Java has a bad reputation for client side development.
I've done a little client side and it was painful.
I'm not all that thrilled with the implementations of the interpreter provided for clients.
Everyone already has their own preferred tools for server side stuff.
So nobody wants it unless they're already a java programmer.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
Look harder. A lot of commercial Web sites are written in GWT, they are just not going to make this very public. Take a look at a DealBook Web, for example: http://www.gftforex.com/software/dealbookweb/ It is just one amazing example of real-life use of GWT technology.
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 find that it doesn't work in Opera (for the most part) GPokr and Kdice don't and I actually saw Gmail's Google Chat actually work for the first time yesterday within the Gmail webmail client. I know you could load the chat window itself in it's own window and it would sort of work.
I though Opera was supposed to be the browser that abided by all the standards. Then why do so much stuff not work in it? Is it Opera, or just web developers not sticking to standards?
GWT was built on the idea that making a good UI using HTML and JavaScript was soooo terribly hard that you would rather use the AWT. That's a horrible solution for a problem that has a well-trained workforce already assigned to it. Why can't we come up with a 100% abstract universal user interface description language and compile it everywhere? I don't think we have tried hard enough. We have failed, and learned some things from our mistakes, and made some cool next-generation toolkits like SWT. Let's take it to the next level, boys and girls.
I looked into learning GTW about 6 months ago and found the lack of GOOD documentation and tutorials troubling. This was the main reason I stayed away from it. I didn't really find a good community in which I could ask questions to.
The second part of it is that I do web projects and programming for fun, not for business. With that, I rent a server instead of hosting my own. A lot of companies I see that offer the ability for you to host small websites, don't offer the ability for you to build a GWT application and host it on their site. Which means you have to either build and host your own server to do it or you have to pay more to rent part of a server to do it. I'm only paying 5$ a month to rent, and I'd like to keep it that way. When it comes to doing what I want to do in PHP with an AJAX framework (XAJAX in this case) or moving over to GWT and having to find a whole new setup to do it, I'll stick with PHP.
I tried it just when was released and I couldn't port it to PHP because was to hard (some conversions classes, some ports...).
I know it's a Java based framework, but since we use PHP where I work, this was discarded fast.
So sad... I'm still curious to see a real (and easy) port for PHP...
vype.com uses gwt for their chat client
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
Am I using GWT ? No. Hope this helps, thanks for asking. kthxsbye.
I get this on my command-line:
Web 2.0
^W: Web
^W:
The GGP might only be describing his own system, but he isn't trolling.
My geek licence, BTW; I should have realised that not all systems are the same in this regard.
Wikileaks, no DNS
I loved the concept of detecting run time errors at compile time... though I've yet to even download it.
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.
We investigated if GWT would be usable for a big and complex web dev project (in a top IT company), and we found out the technical quality of GWT is pretty high. It just have a fine level of abstraction, allows to custom everything, and is pretty performant. The problem is licensing. They pretend that it's licensed under the Apache license, which is not true as they are 3rd party programs included that makes using GWT in a commercial application a legal nightmare. At least this was our conclusion. For a good counter-example, look at Eclipse and RAP. If Google could clean the licensing issue, they could easily gain acceptance outside the private/"just try it" out domain
The reason you might not see a lot of sites using it is because it makes more sense to use it for new UI projects. You can rewrite your web app to use it, even taking advantage of existing Javascript you have written (using JSNI), but that's probably a huge undertaking if you have a reasonably complex site. GWT is really new, so you can only expect really brand new sites to be using it.
One of the other reasons you may not see much usage of GWT is that it is being used for intranet applications, probably more so than public internet apps.
I think GWT is a great approach and plan to use it for my future webapps. Most of the criticisms against it are misunderstandings about how it works.
I am actually planning to rewrite one of my web apps (written with Spring MVC, DWR, and a mix of Javascript libraries) using GWT. GWT's approach is that much better that I'm willing to throw out the work I've already done.
Is Anyone Using the Google Web Toolkit?
Yes. Someone is using the Google Web Toolkit.
Sadly, unlike WT (http://www.webtoolkit.eu/wt/), the google web toolkit forces me to write java on the server and the client and does not make it easy to have the serverside actions happen on button clicks etc.
What I really want to do it write an application like a gui where I write in a single language (c++/Java/whatever) and it deals with the browser and the server and I don't have to think about it, when a button is clicked this function is called, if it's on the server, great, if it's on the browser fine. Wt is very close. What it is missing is the graphical designer that Qt has. Add that and it will be quite the tool!
-- Many men would appreciate a woman's mind more if they could fondle it
The company I work for uses it and we love it. We develop a closed webapp so nobody except our customers sees it. I don't know how we could've developed such a large and richapp webapp without it.
It's called lurking.
Who said Freedom was Fair?
I use it for my day job and love it. Its not outwardly visible that it is being used but I suspect websites just aren't running around advertising what toolkit they are using.
A few years ago I found this code somewhere, not sure where:
<script>
var x=false;
/*@cc_on @*/
/*@if (@_jscript_version >= 5)
try {
x = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
x = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
x = false;
} }
@end @*/
if ( !x && typeof XMLHttpRequest != "undefined" ) { x = new XMLHttpRequest(); }
var n = String.fromCharCode(10);
x.open( "GET", "data.php" );
x.onreadystatechange = function() {
if ( ( x.readyState == 4 ) && ( x.status == 200 ) ) {
var r = x.responseText;
var l = r.split( n );
// do stuff with l array
}
x.send( null );
}
</script>
It is the most reliable and useful thing I have ever found, and I have built a bunch of websites that use it. Basically, your data.php page feeds it linefeed-delimited data, then your page responds to that data. Why do we have to use all these crazy libraries and their associated overhead to do this very simple task? You can keep your frameworks and toolkits, this little code chunk gets the job done.
>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.
My company use it for a large web application in waste management domain. We use IT Mill API for GUI, a toolkit based on GWT.
http://www.itmill.com/
If your main concern is using the same language on the server and the client, maybe you need to look at a different language on the server. I used to think it was really neat, but JavaScript has a lot of problems that make it a less than ideal server side language. And when my last company started to switch to .NET on the server, I realized that really, the only benefit (besides not having to know more than one language) was that it made maintaining our JSON serializer/deserializer code much simpler.
Personally, I've never considered GWT because I know JavaScript really well, and I don't know Java. I've also never felt that there's anything all that difficult about building GUI apps using JavaScript/CSS once you have a decent DOM & XMLHttpRequest abstraction layer. Throw in Firebug, and I actually thing it's easier than building GUI apps in any compiled language. Maybe it's just because I never drank the static typing Kool-Aid.
Finally, even if I did know Java really well, I don't really like the idea of using a client side platform that ties me to a specific server side platform. (Which is why, aside from its sheer bloatedness, I never looked seriously into Atlas / ASP.Net AJAX when I was doing .NET development) There's no reason the two should be tied together.
If I don't put anything here, will anyone recognize me anymore?
There's a saying that "It's hard to teach the old dogs some new tricks" (or sth like that) and this also might apply here. But the major reason why the GWT isn't widely seen in use is I think the lack (for now at least) of a strong need for it. I mean, most web apps I see still don't rely heavily (not to mention entirely) on JavaScript where using GWT as an alternative might be a big win (in some cases). There are some exceptions of course: apps which involve some serious browser coding (like Gmail or Google Maps though none of them done with GWT) but they're still in minority.
So, in my opinion, the GWT is still waiting for its time to come, i.e some serious explosion of demand for desktop-like web apps in the browsers where it would justify the effort of learning & using it (of course for those who like Java/static typing/the tools around it and hate/don't want to learn JavaScript or get used to its dynamic functional-like nature).
Now, if it goes about some "major" web apps using GWT (besides those mentioned) I know of one more: Lombardi Blueprint [http://www.lombardisoftware.com/bpm-blueprint-product.php]. There's also a Google I/O 2008 session "Using GWT to Build a Diagramming Tool" done by the guys who build it [http://www.youtube.com/watch?v=xh5Vo_drhDE].
PS: sorry for my crappy English - it's not my native language.
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 never used glassfish. I'm curious why you recommend it so strongly over JBoss.
For app servers and servlet containers, I've used Weblogic, Websphere, JBoss, Jetty, and Tomcat, and I couldn't say that one or the other of them made my life 1000x easier. ;)
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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...
Thanks for the info.
Checkout http://www.theclassconnection.com The website is developed entirely in GWT
* Any UI toolkit is going to limit customization of the UI to an extent.
This is a trade off for compatibility and maintainability. If you want to make really fancy UI's that push the limits of HTML and CSS then good luck maintaining that across browser version.
* The javascript is generated from Java code on the client side, and best supports Java code on the server side. This presents two issues:
o Good luck finding a cheap Java host
o You are tempted to use cool things like Hibernate, which presents a problem when entities are being passed to what is ultimately javascript code.
Then don't use Java on the server side. GWT supports standard Ajax and JSON and XML. If you want to use the big tools then you'll need to understand them first.
* Deploying was always a bitch
Really? Step 1) compile, Step 2) FTP
* Writing a webapp in a statically typed language seemed.... wrong.
Writing a desktop app using Web technology IS wrong. Better use real software development tools if you want to build thick clients... trust me.
It looks like http://www.songboxx.com uses GWT (once you search for something), but it seems like it is on a SLOW server. Pretty neat though.
Cuban Music MP3's - cuband.com
I'm doing all sorts of fancy UI stuff with jQuery, all cross browser compatible. And notice I said it "best supports Java code on the server side," not exclusively Java on the server side. Being able to pass java objects in pseudo-native fashion with all serialization and whatnot being done behind the scenes is a very nice feature, and was one of the things they were selling the platform on when I got started in it.
I should clarify regarding deploying. If you are deploying strictly html/generated javascript, it is trivial. Not so much when it involves making it play nicely with a Java backend in a deployed state.
Similes are like metaphors
* 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)
One site that I've noticed that uses GWT upnext.com.
I've used GWT before and think it's a well done framework. It simplies AJAX dev a lot and really allows you to get a desktop like UI up and running very quickly.
One reason though why it may not be catching on is SEO. Full out javascript heavy ajax apps are increasingly search engine unfriendly.
This is one area where google needs to work with itself. They should make GWT work with the Google Search Engine, or make the Google search engine able to index ajax apps properly.
Right now, ajax apps seem to get 'punished' since its hard to define links to them.
I beg to differ. I think that GWT is more directed at "traditional" UI designers who are trying to make the move to web based applications, but want to do so without sacrificing code quality and maintainability. We're seeing an increasing number of apps move away from traditional server-side page rendering, since more users appear to be asking for desktop-like response from their web apps. (hence "web 2.0" or whatever awful name is being used for it now)
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
"You write your front end in the Java programming language and GWT compiles your source into highly optimized JavaScript." Java that turns into JavaScript? Is that like vomit that turns into diarrhea? Thanks, but HELL NO.
This is going to come across as arrogant but what the hey. GWT is excellent and if you're not using it for any new browser based front end development I think you're missing out on the best development environment currently available. I really urge everyone to give it a go. I work on a commercial product, blueprint.lombardi.com, with a UI completely written in GWT. This is a product for which we charge money, not a demonstration or proof of concept. It supports IE6, IE7, FF2 and FF3 and includes features like drag and drop, animation, and automatic graph layout and line routing. I spoke at Google IO this year, you can see the presentation here Using GWT to build a high performance collaborative diagramming tool for a more in depth look at what we've been able to do with GWT.
We originally started building Blueprint using a mixture of flash and html, then tried the dojo toolkit and settled on GWT at the start of 2007. Flash and html didn't work well together we wanted to be able to drag and drop between the two environments and that didn't work. Besides, in the real world you have to support some very old versions of Flash and there are people who can't, because of corporate policies, upgrade to more recent versions. We did manage to produce an alpha release of Blueprint using dojo but it quickly became apparent that it was not going to be maintainable. Switching to GWT was a breath of fresh air. You get all the advantages of the fantastic java tooling that's available these days. and hosted mode debugging makes finding runtime errors easy.
The fundamental parts of GWT are the java to javascript compiler and hosted mode execution, the widget toolkit and RPC mechanisms are excellent but are not what makes GWT so good. The compiler takes the java code you write and applies very aggressive optimization to create javascript that is more compact (in obfuscated mode) and that executes faster than code you would write by hand. I kid you not, I have a post here Overlay types, the dom and deferred binding in GWT 1.5 that demonstrates just what I mean. You can reliably refactor your code using modern IDEs, something that's not possible with raw javascript.
Hosted mode execution lets you single step through, in, for instance, Eclipse or IDEA, your GWT java code while it controls a the UI in a browser. Nothing comes close to providing that level of productivity when you're working with raw javascript. It is frankly amazing when you see it in action.
GWT does a good job of hiding difference in browser behavior but you still have to be aware of CSS behavior differences between browsers if you're trying to do some of the fancier things you see in our Google IO presentation.
development.lombardi.com
I'm a java guy who tried GWT and I got disappointed when tried to integrate to my current IDE, the eclipse project creator is so narrowed that I couldn't work it around easily. The winner lang-framework will be something very similar to GWT. Imagine use swing directly in the browser without all the jvm load and plugins, etc. Today with javafx, air and silverlight they are trying to do that. Something standard and open will come up, but thanks to companies like google who research and releases products like gwt that objective is nearest each day.
I've been using GWT for around a year now, and have built several application like websites for my company (from medium sized to fairly big). The sites are currently actively developed and maintained, and are used by hundreds of (paying) end users.
There's a lot of myths around here about what GWT is and is not, and a lot of "experts" that actually haven't touched the thing.
For me using GWT is a pleasure, and has saved A LOT of time, I can code for the web using Java and am (almost) completely isolated from "low level" coding, browser incompatibilities, and CSS hell (and yes, I've been there a lot of times in the past).
As for having to look at the generated JavaScript, that's rubbish, in a whole year I've had to do that ONCE, to figure out a strange bug I was facing.
The lack of built in widgets is real, but is well solved with GWT-EXT if you don't need to customize a lot.
The masking of client-server ajax with an RPC like layer is brilliant.
You have a complete Java debugging environment, that's priceless.
As to why you don't see it take off, I'd say that there's so many frameworks popping up everywhere, that it's almost impossible for one to dominate the market. There's always some guy that prefers this or that language and environment (as you can see by other posts), and somewhere there's a framework to suit his taste.
For me the choice was about productivity, and I'm happy with it. Also, I was coding stuff from scratch and didn't have to "glue" GWT to some less compatible technology. If someone already has a mammoth project in another framework/language/whatever, then you have the resistance to change, that actually might make sense, if you end up spending your time trying to glue your stuff together in awkward ways.
As a happy developer, you can bet that, whenever possible, I'll use GWT.
www.EatPoopUCat.com
GWT was our solution to creating an interactive site without having to learn a lot of JavaScript/HTML/CSS tricks. It seems like it worked out pretty well, but you can be the judge.
I read two books about GWT and I like it a lot and plan on using GWT for my future projects at work. Although GWT is very promising, it comes with a steep learning curve. You need to know quite a bit to be productive. For quick prototyping I still prefer Hamlets (http://hamlets.sourceforge.net/). My $0.02
Rene
I am currently using the GWT a ton, in almost every project I am working on, there are some open source projects and some contracting projects that are using it that I am involved with. I am currently writing a web front for a reservation system and using JSF to power the UI and I am finding that it is hard to get the level of user interaction from the JSF tags that are out there, so I am integrating GWT into our JSF pages to get a more rich experience for the user and to speed up my development. I love the design and simplicity of the GWT. If you are concerned with the amount of JavaScript generated, you should check out the next version of the GWT (1.5).
First I want to welcome the slashdot readers that decide to play some poker or dice (like risk). I also want to provide a quick response to the comments on GWT. The problem with some of the discussion is that it doesn't recognize that software development is a huge industry not limited to scripting, the web, and UI's. I don't think its fair to say that GWT isn't catching on, and I can attest from book sales that it is definitely well used, but perhaps its fair to say its not catching on with web developers. I find that web developers in general are like the lead singers to a rock band (no disrespect intended). They're on the front end, they get a lot of credit, people talk about their lyrics, and they're on the cover of Rolling Stone. But the music industry is huge and much more than the front man. So when a new type of music comes along, say its Jazz, and it not about the buzz or doing something cool but instead more purely about the music it can still become immensely popular if not more so than lead singers - but its easy to conclude that it is not popular. I hope the analogy isn't too far fetched. You see, GWT, like good Jazz, doesn't have the promotion of popular music. Even though it's backed by google it's clear that Google doesn't promote a lot of its projects. GWT goes against what traditional web developers are comfortable with and as a result isn't popular with them and doesn't make it to their blogs or web 2.0 websites. However the massive market of desktop and server side developers really get GWT since it uses strong software development concepts and is capable of building thick clients. They want a piece of the web browser since it is so ubiquitous but they just don't have the blogs and web 2.0 buzz of the web developers. In the end it's not about which tool generates the most buzz its about the quality of the products you build. I for one, am extremely happy with the quality of products I can build with GWT.
GWT has been absolutely fantastic for me. My project is basically a kiosk with a specific functionality built in. This is nice because I didn't have to worry about integrating with any legacy UI.
I'll tell you this tho: I'm never writing JavaScript again.
dimdim is using gwt. it's a free livemeeting alternative.
GWT is nothing less than a completely original approach to web development. So, its client-centric approach could hurt old Web habits, particularly server-minded coders.
Furthermore, there are now maybe hundreds of JavaScript Libraries and Ajax Frameworks. A cleanup is in order. Of course, it takes some time...
These facts can explain the relatively slow adoption of GWT.
That said, let me simply explain our experience.
So we ask ourselves: Which tool will be the good one considering our project itself, our team composition and our future developments? So we did a small survey.
After some exploration, our short list of preferred or most likely tools includes RSF with Dojo/Dijit, JSF with RichFaces, jQuery, ZK and GWT the Google Web Toolkit. Further review concluded that the best technology was the Google Web Toolkit.
At the end, our main argument was that our team is essentially composed of Java developers with little knowledge of JavaScript.
As a matter of fact, GWT Cross-Compiler takes client side Java code and generates cross-browser JavaScript. When compiled the Client-side is then pure JavaScript and HTML. You can see JavaScript as the 'assembly language' of the browser.
Our project, OpenSyllabus was entirely written with GWT and Java. So, we have never debug not even one line of JavaScript code for a project which has much as 400 MB of source-code (for both client and server side).
In the ideal world, the Java developer would never have to write JavaScript code. This is a fulfilled promise of GWT.
With GWT, Google bets on the 6 millions Java developers community out of here.
Advantages of GWT:
* Development time efficiency is our favorite advantages of GWT
* Only one language : JAVA
* GWT applications are faster than traditional page-based equivalents, and definitely require fewer HTTP round-trips
* Requires no browser plug-ins, Web Start or JVM No downloads, no installations
* Powerful & efficient in resources usage both network & server
* Compatible with all recent desktop browsers
* Open source, free and well documented
* Supported and improved by Google and Open Source community
* Rapid development and debugging with common IDEs as Eclipse
* Familiar to Java developers, particularly those having Swing experience
* Benefit from the Open Source Google API ecosystem
Disadvantages of GWT
* Need a good knowledge of Java * Components (Widgets) are from different sources and qualities * The built-in UI components library could be more extensive * Depends on cross-compiler performances * We have to keep an eye on security issues.
Inherently Ajax (GWT and JavaScript libraries) create more opportunities for possible attacks if the application is not designed with security in mind. * GWT is a Toolkit not a FrameWork
This means that GWT does not prescribe a way to build an application. So, for large application we have to set our own guidelines * CSS support
It was the worst cross-browser problem we encountered
GWT is not magic but has the potential to be the "next big thing" for Web 2.0 development
I work for a large consulting firm and have found that GWT (gwt-ext specifically) is great when our clients have rich client requirements, but do not have the ability to support large scale java script AJAX applications. GWT allows us to code the product in Java, document it, then hand it off successfully to an internal support team composed mainly of inexperienced java "developers" for maintenance.
Is that, since it is a Java to Javascript situation, GWT has to compete with Java. And here's the problem with that: If you want to do anything with GWT that is non-trivial, it's kinda a pain. Why? Because Java already has stuff like EJB3, RMI---GWT does this via serialization servlets, but these do very very little to help you with things like a) complex data types or b) nested data sets or even c) disconnected objects. The main problem is that there is no persistence built in. Rather, you have to roll your own DTOs to translate between the very very very simple types that GWT *CAN* understand and the complex server-side types. I used this on a bigish project about a year or so ago and simply maintaining the code that mapped my GWT DTOs onto my Hibernate models was enough to permanently disqualify it for me. For smaller projects, however, GWT is a dream.
We're currently using GWT to build web-based business applications in Thailand.
Basically, if you're a Java developer, then I don't think it gets any better than this - you can share code between the client and server, and the GWT-RPC works extremely well.
The GWT abstractions means you can create cross-browser applications with a minimum of effort, and their use of "deferred binding" together with agressive compiler optimizations means that the resulting javascript will likely run faster than would be reasonably possible if done by hand.
I'm convinced that there's no way our team (2 people - my girlfriend and myself) would be able to create web-based applications as complex as we're doing in a short time using any other technology with I'm aware of.
Note that I said "our team" - meaning developers who specialize in builing enterprise business applications in Java, who only have enough knowledge of Javascript to get by on. Other developers who use a different server-side language, or who consider themselves javascript ninjas, might not find the benefits as great.
In our spare time we knocked up a puzzle site which uses GWT - see http://puzzles.radworkz.com./ We also have J2ME and Swing versions (not available from the site currently), and will be supporting Android once we get some spare time - all made relatively easy as thanks to GWT we can use the same Java source code on all platforms.
The rule engine JBoss Drools uses GWT, it's worked out very well for us allowing us to build a fast and complex app. The base set of widgets and theming with GWT still isn't good enough yet, although 1.5 is an improvement, so we used EXTJS with GWT, using the GWTEXT wrapper. However since the EXTJS license change we now need to migrate to something else, probably Dojo but still using a GWT wrapper.
We have a number of blogs with screenshots with our latest work:
http://blog.athico.com/2008/07/drools-50-m1-new-and-noteworthy.html
http://blog.athico.com/2008/04/brms-for-drools-5.html
http://blog.athico.com/2008/07/integrating-rolodex-to-guvnor-for-image.html
Mark
http://blog.athico.com The Drools Blog
I have to deal with GWT on a weekly basis. It has to be one of the most frustrating ways of using ajax. I have to keep on top of all the new generated files it makes based on hash sums that replace the old data (which a lot of times is the exact same) ... not to mention designers have a hell of a time making modifications to the generated JS files making the designers frustrated and, when it comes to ajax stuff, close to useless.
Be kind to your friends, don't use GWT.
I recently tried to write my first real AJAX page (a small and simple page with a date-publication selector, and I had a time getting the page to work on IE7, Firefox 2, Firefox 3, and Safari. (Maybe it was because I was just trying to retrieve HTML, containing tables, and dynamically embed it into the current page).
Anyway, GWT has some strong competition. How does it, and it's competitors, do when it comes to cross-platform compatibility? If I just want to retrieve a table or widget, or piece of HTML and place it in the current page, are some better than others?
(Please don't tell me that web 2.0 is based on the idea that everything involves encoding all data as XML or JSON, and writing an XML/JSON-to-HTML interpretor that runs on the web page).
What ever the differing beliefs of the churches of vi and emacs, most of them (except a few old curmudgeons) use bash, and in bash, two ^Ws is sufficient to delete "web 2.0".
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.
Frameworks such as ExtJs are soooo much better to use if you're looking to develop an ajax-enabled web app. I've looked at GWT and Yahoo's YUI libs and ExtJs by far has a more consistent, feature rich API - and gets better with each release.
GWT is really for java developers that dont want to get their hands dirty with javascript.
I've been using GWT a bit to modify an existing velocity based application.
It was a bit of work to get my head around, until I realised it was two separate things.
First, it's a nifty way of writing GUI widgets in java, and auto-converting them to javascript.
Secondly, it's an RPC mechanism for AJAX like cleverness.
Now for me, that second one wasn't so necessary. I have a nice REST-style back end with an existing data structures. So once I stopped trying to splice GWT/RPC on top of that, and just used GWT for widget creation (using POST and GET from GWT), it all went swimmingly.
I think there is an expectation that you'll do your entire site in GWT; however I've found it quite useful to just do some nice widgets in GWT, and keep most of the site classic velocity; it's easier and faster to maintain that way.
I think GWT will take off when there is a richer 'standard' widget library - when you can build an editor like gmail's in as a single component. But at the moment gmail doesn't use GWT, presumably because it's tricky to do something that complex.
YMMV :-)
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird.
Good JavaScript libraries like (jQuery ExtJS or YUI) makes much easier to use JavaScript but it's still JavaScript!
In fact, comparing Java and JavaScript is not a fair at all... From a software engineering perspectives, JavaScript is too weak to hold water.
As Brendan Eich, the JavaScript creator, himself recognises, JavaScript was designed to add a little bit of animation or a little bit of smarts to Web forms and Web pages.
Furthermore, GWT has a JavaScript Native Interface (JSNI) that allows automatic inclusion of external JavaScript and directly interacts with JavaScript from Java and vice versa.
I might perhaps add that GWT compiler generates faster JavaScript than you can write by hand!
Finally, there are extensions available GWT-Ext and GWT-Query which does what Ext-JS and jQuery does but calls the GWT compiler to produce optimal code.
GWT does for Java what MS ASP.NET AJAX does for C#/VB... Having used both - Microsoft's implementation is far better. Both are bad ideas for anything more than a sales mock, however.
Web apps need to have code written by someone who understands it from the ground up and has had to maintain a site longterm before. You just can't know the dependencies in something like GWT/ASP-AJAX as well as you could if you wrote the JS ground-up.
I agree w/ the comment on Progressive Enhancement but long for the day it isn't necessary. I want enhanced and I want it NOW!
You won't see a lot of web sites using GWT because GWT is better designed for desktop-like applications (internal use). It doesn't mean than nobody is using GWT...
I wrote a Java IDE in GWT for a project at school. GWT was the slickest toolkit we could find -- we didn't touch nary a line of a javascript. It was a lifesaver and I have *no* idea why it's not used much more.
>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
Well said, and might I add that shouldn't the goal of all develop be to incrementally improve the performance of a site by code optimization, once you've gotten your requirements met? I don't care if you have a Fiber connection it's a waste of bandwidth to serve up substandard code and content when you can improve both.
It's also because javascript can't get basic math right. Try: 13.34 + 6.65 in javascript, and you'll get 19.99000000000000002 Go ahead, try it if you don't believe me.
There is a web conferencing site which uses GWT www.dimdim.com.
I personally have been using GWT for a year now mostly in the areas of public health.
I found it to be powerful and efficient resource wise any J2EE developer will not have to go through any steep learning curve(learn Java script or proprietary libraries).
It produces better javascript than hand coded java script.
Ref: http://www.youtube.com/watch?v=nvti32k4xyU