Slashdot Mirror
Is Anyone Using the Google Web Toolkit?
eldavojohn writes "After seeing some applications from Google and participating in the Google Codejam (which seems to be built using the GWT), I kind of expected to see websites spring up left and right based off the GWT. Well, it's been a year and a half since they open sourced it and I have to admit that I am more than a little disappointed by its low profile in the UI community. I've been trolling their blog and have seen a few books out on it. But the one thing I'm not seeing is its use outside of Google. I've worked through the examples and tutorials at home and though I've been impressed with the speed, I am disturbed by the actual result — a whole ton of generated Javascript. But this is the first UI technology I've found where I can write in the native language of the server (Java) to generate and unit-test the UI code. Aside from Google's use and the games of Ryan Dewsbury like KDice & GPokr, does anyone know of major sites using the GWT? If you don't and you've used it yourself, why isn't it taking off? Is it too immature? Is it a solution to a problem that already has too many solutions? Is it fundamentally lacking in some way?"
Because a big company open sources something we're supposed drop what we're doing and run to the next best thing?
JavaScript libraries and toolkits multiply faster than rabbits, there's a new "framework" coming out each week, and some of them had strong developer support (i.e. people willing to answer my stupid questions in forums) long before Google came out with their stuff.
Not that it's bad or anything, but in the end it's all JavaScript anyway, and learning two different ways to get to the same goal (an interactive site) is generally pretty low on everybody's priority list.
Are you using Google Sparse Hash by the way? Why not?
is that everyone wants to roll their own.
How we know is more important than what we know.
To me, the biggest problem is abolutely no fallback to non-javascript browsers. I'm not so much worried about users, but search engine bots won't be able to spider me and drive traffic to me.
-Bucky
...just not as much as you might expect. Part of the issue is that it's designed for when you develop your application from scratch. Generally with the intent of developing a desktop replacement webapp. The only problem is that not many companies are investing in such apps. They're investing in using DHTML/AJAX to make their sites more interactive rather than replacing the HTML interface outright. In that situation, GWT is not the ideal solution. (e.g. For quite a while, you couldn't even have more than one widget per page!) It works though, so you'll find it pop up here and there.
On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.
Javascript + Nintendo DSi = DSiCade
We built a Proof of Concept Report Designer and Report Viewer on top of BIRT using GWT for the interface. It had some cool features, like multi-user real-time report development, versioning, and tie ins to the commercial report repository that the company that built BIRT sells. It had a real nice WOW factor to it, but in the end, it was just a pretty POC that we could show at conferences, it would never replace the desktop version due to responsiveness (imagine, an Eclipse app that is more responsive than something else...) IMHO, web technology is just catching up in the UI space to where desktop apps were like 15 years ago, and Web 2.0 is still a tacky buzzword. To do some things that are trivial in a desktop app requires a lot of convoluted steps (callbacks, etc). And even things that would be done the same way still requires a network round trip to get information that desktop apps don't suffer (simple tasks like dynamic drop-down or list population). GWT is a step in the right direction, and the ability to debug in an IDE both client and server side components is very nice.
I'm a long time web developer but I've never even cracked open the box on GWT, so take this with a grain of salt.
The idea of depending on generated javascript scares me. I'm against writing Javascript in Java, Ruby, Python or anything else. Javascript is just too much of a beast to debug to leave everything up to an opaque framework, and I want to be able to get my hands dirty. I like the smaller and more traditional open-source style frameworks. Prototype, jQuery, MooTools, even Dojo just scare me a lot less.
It could be totally irrational, and it also could be the fact that I tend to build web applications that need minimal state and pretty basic AJAX interactions. Nothing anywhere near as dense as, say, Gmail. If the right project came along I'd definitely give it a more serious look.
There's a lot of corporative GWT-apps because it's, probably, the best toolkit for rich-client web applications.
However, it's not used much in the public web because most sites just don't need that kind of user interfaces.
Also, GWT is incompatible with web spiders.
I 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.
> 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
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.
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.
... 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.
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.
Personally i entirely agree... although my reasoning is not so much 'Ewww' its java as 'I don't want to have to install yet another server module'.
After screwing around with a lot of the well known JavaScript libraries (notably: Prototype+script.aculo.us, jQuery, Dojo and YUI) as well as a GWT, i settled for Prototype+script.aculo.us - simple, and easy were the main reasons behind this. In the end GWT didn't even come into the decision due to the restriction on server side language.
For me, using something like Prototype makes the entire concept of graceful degradation easy.
Also, Prototype isn't something i mind loading for that small quick page that needs an updating panel - where as most of the others seamed like excessive bloat in this case.
(and if you suggest that pain JS would be better than loading prototype, it wouldn't relay, blasted browser/ajax compatibility)
You must beone of the REAL PROGRAMMERS one keeps hearing about who do not use compilers...
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.
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!
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
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!
GWT *does* do this, as detailed on their code FAQ: http://code.google.com/support/bin/answer.py?answer=60559&topic=10211
It's actually a pretty elegant solution. But then again, it's not really a "toolkit", which is usually a huge clot of Javascript, called in places in your code. It's a fantastic optimizing compiler. And though this is mentioned alsewhere, it's more for keeping yourself from having to maintain horrific hacks and large, unweildy Javascript codebases. Java is far easier to manage in a large project.
"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
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
Could you explain this? GWT doesn't necessarily have to be run in a servlet container, it can be precompiled and left on the server to interface with things like PHP or Python, or just use the JSONRequest support in GWT. So, there's no actual advantage to using something like YUI or Dojo, since GWT can call back to whatever your server-side component is in the same way that YUI, Dojo, script.aculo.us, etc could.
Dojo was *horrible* to build an interface in, especially when the Dojo team kept breaking their API with every release, usually in subtle ways that weren't necessarily apparent.
"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
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.
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 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 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.
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
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.
>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.
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.
So you write all your software in binary?
How is writing in Java and compiling to JavaScript any different than writing in Java and compiling to bytecode?
There are some good reasons mentioned here, but I wanted to throw in my 2 cents as well. I have used Wicket professionally and loved it. I evaluated the GWT on my own time and was moderately impressed. HOWEVER:
Most people that are in charge of project are not going to pick a "new and cool" component-based web framework like the GWT or Wicket simply because they are afraid of what they do not know. I am not talking about some guy providing professional services (those are the people mostly using Wicket and GWT actually) but about primary architects at medium to large corporations with multi-million dollar budgets.
Why do they not make what I think is the right choice? The fear is part of it of course, but these guys are good, smart professionals, so there must be another reason. I believe that reason is the glut of web frameworks currently available on the Java platform. Even evaluating one takes time a lot of these people do not have. If they cannot evaluate everything, they cannot agree on anything, so there is no industry wide consensus. Most of these people are very careful risk-averse individuals (a good trait to have for an engineer), and there we are.
I've 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.
I think a lot of people take a casual look at GWT's RPC mechanism and walk away with the assumption that their back-end has to be done in java. My project happened to use a java backend, and the stuff you get "for free" with their RPC mechanism is really nice but there's no reason you can't use an ordinary JSON service written in you're favorite backend.
It's like taking a quick glance at a swiss army knife, noticing the cork screw, and tossing it aside saying "meh, you need a bottle of wine to use this".
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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)
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?
It's a matter of layers.
The Java that is compiled to bytecode expresses pretty much exactly what I typed in a well-understood manner.
When you write in Java for this framework, it is then interpreting your Java into a much higher level expression that assumes all kinds of things about what I want done in the Javascript.
It's the inherent disconnect between the language I write in and the language that gets output in this system, that causes the trouble... you are writing code one step further removed from the eventual realm of execution. Every step you take away from that final realm adds to your peril. In this case you especially have potential for issues just because of the varied nature of Javascript runtimes. Java itself at least has a rigorous test suite for VM's that makes it much less trouble prone to take Java code from one system to the next (itself after all being a step removed from compiled code).
So yes some degree of layers are safe, depending on the care that has been taken in stepping down. But generally as I said, the higher you go the worse off you are - and so as a general rule of thumb, code generation is evil.
You have been warned.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
dynamic code generation is evil
GWT does not use dynamic code generation. The javascript that is emitted by GWT's java-to-javascript compiler is generated at build-time...in the same way that x86 code is generated by gcc at build time.
Moreover, the code that is generated is not source code, which is the context in which most people use the rule of thumb that you imply. Rather, the generated code is, in essence, object code: you're not intended to read it or modify it. It's just deployed and executed, plain and simple.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
You must beone of the REAL PROGRAMMERS one keeps hearing about who do not use compilers...
Yes, only cat. :-)
Like I said, it's a general rule of thumb. I also said there are no exceptions but that's to keep people who do not realize compilers are an exception, safe. Otherwise everything starts to look like an acceptable exception. It is only when you understand fully that meaning that you can choose what are valid exceptions for your needs.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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
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.
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.
Care to elaborate with some specifics?
A gin in the hand is worth two in the bottle.
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 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).
Moreover, the code that is generated is not source code, which is the context in which most people use the rule of thumb that you imply. Rather, the generated code is, in essence, object code: you're not intended to read it or modify it. It's just deployed and executed, plain and simple.
To me, it's still code generation and as I explained in other messages another step removed from the what you are writing. There is inherently a difference between what you write in Java and what Javascript can do, and I simply do not trust that disconnect to be resolved well.
I would far rather keep the transaction between myself and any client side UI purely data driven and code for the client side specifically, rather than have a half-hearted interface extracted for me from the server side code. I have tried similar approaches over the years and found that approach rarely yields a good UI, though it can always spit out a tolerable one. Until you run into bugs in the generation framework...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
There is inherently a difference between what you write in Java and what Javascript can do, and I simply do not trust that disconnect to be resolved well.
Thank you for replying. I'm curious to know if you can think of a concrete example to illustrate what you're trying to get at here.
I would far rather keep the transaction between myself and any client side UI purely data driven and code for the client side specifically, rather than have a half-hearted interface extracted for me from the server side code.
I'm also having difficulty mapping what you've written here with some aspect of GWT or how it is used. Although I agree that what you describe sounds frustrating and undesirable, I'm not getting how it relates.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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".
Thank you for replying. I'm curious to know if you can think of a concrete example to illustrate what you're trying to get at here.
Sure, one thing I can think of is related to a DND (drag and drop) example.
It's abstracted away the actual Javascript involved in handling things, and furthermore moving the expressions for processing events to Java. I am uncomfortable with the limitations imposed by having to handle events by writing Java when Javascript would be able to more naturally handle events. It looks like it lacks flexibility that a Javascript framework would offer through language features.
In general there's the whole totally parallel library path feel to using the GWT, where it looks like Java but really ends up as Javascript and can get confusing in terms of mixing similar GWT constructs with Java code. I don't like it for the same reason I never liked JSP pages, where you intermingle code and HTML. It's too easy for a developer to get confused and do something odd.
Sorry I can't give you a better example, but it's the get feeling I get about the whole thing when I look through how it works.
In terms of the data driven thing, I would far rather have a system that is talking back and forth between a pure Javascript UI layer and a server via web calls, or something that generates static data files that pure HTML/Javascript/CSS would then access.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Sorry I can't give you a better example, but it's the get feeling I get about the whole thing when I look through how it works.
This actually makes a lot of sense. If you actually went and read the GWT source code -- and saw their extensive use of the JSNI interface (where java and javascript code reside in the same file), you might be left with the impression that this is how the source of your application needs to look. If that's what happened, then I can certainly understand your distaste for it. The good news, though, is that they make extensive use of JSNI at the lowest levels so that you don't have to. If you need to, you can, but that only happens in extreme circumstances.
I actually got to implement DnD in the GWT application that we wrote. We even looked at the gwt-dnd library (used in the example you linked to), decided that it was overengineered, and decided to hand-roll the DnD code that we needed for our specific app. (Our app is sort-of iTunes-like, where you can multi-select rows in a data table and drag the items over to a folder or playlist). Handling those events was very simple: one call to sinkEvents() to say what sort of events you're interested in, then in the body of onBrowserEvent() you have a switch statement that has a case for each event type you might get. The event types are exactly the same ones that come from the browser. They didn't invent new ones or try to map them to AWT/Swing events or any such nonsense. onMouseDown, onMouseMove, onMouseUp, ... The language constructs I used for handling the drag protocol were two interfaces (DropTarget & DragSource), a DragController class, and an abstract DropController class -- of which I had a concrete but anonymous implementation in each of the two widgets that received drops. Oh, and a DragProxy view that moves along with the mouse. It was pretty easy, in retrospect.
When I write in GWT, I never agonize about what the underlying Javascript looks like. It's very much like writing in C, where you think only in terms of the semantics of the source language -- and rarely need to think of assembly language constructs like load, store, add, and compare.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
When I write in GWT, I never agonize about what the underlying Javascript looks like.
But I think that too is at the core of things, as another poster noted a ton of Javascript is generated and I don't feel like the output is really Javascript friendly in the way other things are or can be.
It's interesting to hear of your experience and I may look into it some more, but the next time server code and myself meet it's probably going to be Grails (Groovy on rails) and one of the more robust Javascript frameworks for the client side.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Please forgive me for continuing this thread for the benefit of anyone interested in GWT. This is the perfect opportunity to illustrate how deep the analogy between javascript and machine language is, since your concerns are exactly the sort of situations that a foreign function interface is designed to address: how do I call out to code in another language, or worse what if code in this other language needs to call back into my code?
We did run into a case where we needed this facility. We had to use a java applet to handle bulk uploads of extremely large files. This applet had a plain javascript API for callbacks into javascript, and we were able to expose methods in our java source code to receive these events (when the upload was completed, failed, or cancelled) and it was pretty easy to do.
The JSNI mechanism counts as one of the coolest hacks I've seen, as it lightly abuses the "native" keyword in java, which causes javac to ignore the method body when it compiles, leaving the GWT designers free to allow you to embed arbitrary javascript in the method body. In our case, it was just a few lines, but it was easy and damned powerful.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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.
>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.
Dojo was *horrible* to build an interface in, especially when the Dojo team kept breaking their API with every release, usually in subtle ways that weren't necessarily apparent.
I'm a backend coder who knows databases, Java, some PHP, and Linux.
I inherited a mid-size PHP project that's just about to ship a 1.0. There were some new features needed. I tried using Dojo for its easy controls and DnD functionality. Absent a really good reason (like a stable API), I would not use Dojo again, despite the slick chrome, for two reasons. One is the tumbling API. The other is that the three big reasons I picked Dojo (dijit.Tree, dijit.Editor, and not having to deal with IE specifics) were buggy, incomplete, and/or unpolished as of 1.1.1. (Why does the default ItemFileWriteStore serializer produce JSON that it can't load back in? Does anyone even test this stuff?) Instead we lightly hacked dTree and htmlArea and that's gotten us to a usable if imperfect state.
The current code was written in 2000-vintage PHP and I'm pretty certain that it's not going to survive until the next major release. The short list of possibilities so far is GWT, move out of the browser entirely and use Java or even PerlTk on the frontend and anything but PHP on the backend, or bring in a frontend coder who has the wherewithal and patience to deal with this web app nonsense.
/. -- the Free Republic of technology.
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.