The only thing I dislike about GWT is the fact that it works like Swing with these stupid action listeners and there’s no real separation between model and view. We use CSS and every widget has its own class so the designer can do whatever he wants, but I have to write a lot of code that just describes the structure of the elements and also what data they contain.

So basically, GWT overcomes JavaScript’s problems (and I don’t understand anyone who prefers to write JavaScript code directly, it’s just hell), but carries over Java’s and especially Swing’s problems.

I’ve worked on numerous web applications before, however the current project is the first major GWT project, and I must admit it’s extraordinary. After an initial couple of days figuring out how to build and deploy the app (and this comes with any new Web framework), we were underway and I was amazed at the speed of delivery.

I like to work in an agile environment, small end to end units, that can be delivered iteratively. This means no massive upfront large scale design (i.e. site maps, site flow, page design etc. something I’ve found our current web designers complaining about in a big way), but a lot of test driven development, especially test driving the UI side (via Selenium).

This also means the developers care an awful lot about the code, and GWT leaves you with immensely more refactorable code than any hand rolled JavaScript. That to me is one of the biggest benefits of using GWT.

Writing rich widgets is also much easier in GWT than hand coding in JS – one particular example was a JS designer handed over an animated temperature bar, which used JQuery to do the animation – the code took a day to write (and I’ve been told he is very talented), which was converted to a GWT animation timer in 20 minutes (without actually looking at the JS code!).

The above point still stands, that if you are doing bleeding edge stuff – GWT may not (but still might) be suitable for your needs. For everyone else with a rich web app to write there’s GWT.

To answer some of the other points above :
Mapping to your server via webservices – no thanks – I’ll take the simple GWT approach.
Map page elements to XML data? Again no thanks – I’d rather not have to go near XML, never mind binding my code to an XML schema.
WYSIWG? Overrated in my opinion (though GWT Designer will give you that if you can’t use the layouts).
Learn Javascript because that’s what it uses under the hood? Well in that case, I’d better learn C, assembler and binary commands too – after all they’re all using that at the end of the day.
Speed? I’ve heard that argument about Java and C++ too. A lot of people spend a lot of time (+ money) writing something they think will be faster in C++, but in reality just isn’t. I’d rather take the easy route and then worry about performance. Plus compilers do just get better.

BACKGROUND:
In designing a TIBCO app, you use a WYSIWG IDE to make everything pretty and then use an IDE to map your page elements to XML data. You can create your entire front end application and then simply map it to your server app via your webservices.

The big drawback of course is that your client app’s functionality is written in Javascript. No fancy debugging abilities like you get with GWT.

Interesting article!

-P.

People also fool themselves into thinking that because JAVA looks much more verbose than Javascript, and is statically typed that they have lost ‘freedom’ and ‘elegance’. As a developer I can only say that the opposite is true. Having all that per browser Javascript abstracted away is pure gold. It lets me focus on making a great web application instead of debugging why X won’t work properly in Safari.

When you add in things like the ImageBundle class (which allows you to bundle a set of images into one HTTP request, without lifting a finger and worrying about the details), browser abstraction and JAVA goodness you just can’t beat it.

If you are looking at Dojo, Ext JS, or another of the giant footprint libs then GWT will most likely have the advantage. These take the “everything plus the kitchen sink” approach and demand it all be implemented via script tags just to get the most basic functionality. They are great for showing off what can be done; horrible for building lightweight practical applications.

On the other hand looking at the combination of libraries like jQuery(http://jquery.com/) with a package system like JSAN(http://www.openjsan.org/doc/c/cw/cwest/JSAN/0.10/lib/JSAN.html) or jsPax(http://www.jspax.org/) a completely different approach appears. Not only is your web 2.0 data loaded on demand but so is your client-side application. This same application can take advantage of well structured libraries like YUI on a piecemeal basis, calling only the needed parts at the time they are required. The notion of building an optimized js for page A and another optimized js for page B get tossed right out the window.

An additional benefit is that the client-side developer is not locked in to the GWT approach, or the Dojo, etc. They pick and choose which parts of which libraries work best for their application’s needs, or build their own if needed. It has been my experience that only the most granular of libraries will meet requirements in every use case where as the higher level ones (i.e. a calendar widget) almost never do. The choice then becomes whether or not you will allow the library determine your look and/or functionality.

The answer to that final question usually comes down to resources and understanding on management’s part. If your team has one or more fluent client-side developers and a realistic timeline then I can see no good argument for GWT, Dojo, Ext JS, or the like. On the other hand if you have only a couple application developers and need to have it out the door yesterday then maybe that is the right path for you… for now.

GWT makes it easy to apply CSS classes to your widgets (more than one if you need to, as well). The CSS file can still be pored over by your designers, tweaking margins and paddings, changing colours, sizes, background images, the lot.

GWT doesn’t need to start on a ‘blank slate’ – you can actually hook into existing DOM objects relatively simply.

There’s also the HTML widget, which allows you to just dump a stack of HTML (statically embedded into your GWT java code, or embedded into a property file, or downloaded dynamically using a HTTPRequest (implemented in GWT using XmlHttpRequest), whatever strikes your fancy. You can interact with this HTML as well, adding GWT widgets to containers with a certain id.

Besides the tremendous benefits of debugging Javascript with IntelliJ or Eclipse, the GWT Compiler makes optimizations to Javascript easily that no Javascript compressor can hope to (without tons of assumptions that limit general purpose JS code)

The result is that for small JS projects, Javascript is a big win, but for large Javascript projects using a heterogenous collection of third party components, GWT wins (in more ways than one). That’s because GWT has alot more known information at compile time than Javascript compilers, or regular Java for that matter.

As an example, take Dojo’s Mail application demo. Firebug Net tab clocks this as 283kb of JS for me. Now look at GWT’s Mail app demo, its 37kb and initializes 3 times faster than Dojo’s. And ShrinkSafe and other obfuscators will in no way close this gap.

GWT aggressively and automatically removes dead code, promotes virtual methods to final methods where possible, folds constant String literals, the list goes on and will grow in future versions of the compiler. It is not simply a Java-to-Javascript translator.

Does this mean every job is a job for GWT? No. Is Javascript a more expressive language? Yes. Does that mean Javascript is the right tool for every job? No.

Any large JS code base is going to have to enforce certain rules and idioms, have a mandatory package and build system, and use a JS compressor/artifact builder that is quite smart about the idioms being enforced — stuff that GWT already provides, but most JS toolkits so far don’t, at the level that GWT is capable of.

With GWT, the compiler removes what you don’t use, and you don’t have to worry about breaking up a large JS code base with imports and build time hints to tell it which granular modules not to include.

Also, how can you ever expect to achieve the speed or light-weightness of javascript. This article seemed very biased and definitely is not written from someone who knows javascript well.

To me it was like Swing for the web app. Sweet, now I don’t have to learn all this cross browser crap and so on.

But now that I know javascript, and have objects and inheritance and pluggable APIs and working fine I have changed my mind. The JS toolkits like YUI seems to be the way to go now. The fact is, Javascript and the DOM API are your tools for interacting with browser. You are going to have to learn them at some point.

So cool idea but in the end I don’t think this is the way things are going. Javacript is powerful enough, and once more java developers are thrown into the web side of the world by their managers, the best practices, tools and processes we are used to will improve. It is already happening with aptana.

Of the dozens of consulting jobs I have taken in the past ten years as a “[HTML/JavaScript/Client-Side/Presentation] [Developer/Designer]” (can I get a title please?) The majority of them started with a showing of the website and the disclaimer “our [Perl/ASP/Java] developers are not so good with HTML”

Early on I resented this, eventually I came to realize that this was a good thing, finally I started to encourage it. Why? Because the server-side application does not, and should not, have any concern or awareness of presentation. Data in, manipulate data, data out. In the web2.0 universe only at the point of the transport mechanism (i.e. JSON or XML) is there any acknowledgment of a display.

So why would it be a good idea to step backwards and deeply embed the display into the server? Every time this line gets blurred all I see are lots of confusion at the management level (1 java developer can build my whole site?) and truckloads of limited use, ugly, and unusable applications that have to be refactored as soon as the wind changes.

When a display specialist is working with display technologies the scales fall away from the eyes of an application and the real potential can shine through. Mash those same technologies into data manipulation and the result is mostly going to be mud. There will be exceptions, there always are, but in the end the bulk affect will be the same.

So, I say “Separation of data and display” and when I see support for things like GWT I have to scratch my head.

p.s. I would like to point out that in the quote “…the home hobbyist is being drawn to GWT by the Google name and expectations of developing substantial web applications straight off, whereas they should perhaps spend some time getting used to Java, GWT, IDEs client/server divisions etc.” there is no mention of DOM or JavaScript and most importantly UI Design.