GWT a Year Later: Was it the correct level of abstraction?

Dietrich Kappe, Thursday, June 7, 2007 @ 8:43 am

A little over a year ago, Ajaxian published an editorial entitled Google Web Toolkit: The correct level of abstraction? In it, Dion raised some important questions about GWT:

• Isn't debugging generated Javascript going to be messy?
• Wouldn't the large size of the generated Javascript make it's use infeasible?
• Where is all of the cool stuff, like effects libraries, etc.?
• Is generating "assembler" in Javascript really the right level of abstraction?

Now that a year has passed and people have had a chance to experiment and develop with GWT, I thought it would be a good idea to revisit these questions. I interviewed GWT practitioners Dr. Adam Tacy and Robert Hanson, who -- aside from working on commercial projects featuring GWT -- have just finish their first book on the subject, GWT in Action: Easy Ajax with the Google Web Toolkit. They were kind enough to answer a few of my questions.

Debugging GWT code is as easy as debugging any other Java application. Just open up the Eclipse IDE, and launch the application in debug mode - the key is to really harness the power of the Java IDE and tooling to ease debugging. There may be some quirks here and there, but in general it is a very pleasant experience.

An issue that is sometimes raised by newcomers to the tool is the lack of a "debug window" component for the JavaScript (think of YahooGUI widgets, etc.) - but that basically misses the point of GWT where 99% of debugging can be applied to application logic in your Java IDE. If you want to hang onto the "printf/println" style of debugging, then in hosted mode it is possible to log to the hosted mode console. For client side code, GWT could be improved to allow for Log4J style log levels. But why would you do this in general when you have access to the powerful debugger in your IDE?

Once you get out of the hosted browser and deploy the project to your site, if there is still a need for debugging you can use the same debugging techniques as you would with any other JavaScript application. Some of our favorite tools include Web Developer and Firebug, two add-ons for Firefox.

One of the initial complaints from JavaScript developers was that the JavaScript code generated by the GWT compiler is obfuscated, and impossible to debug. To quote the Ajaxian story from a year ago, "I can't imagine how scary it will be to have a JavaScript error show up in a browser talking about line 2123 which has "a[b] = push(c)" in it". The author of that piece missed the rest of the story.

On the few occasions that you have an error that can't be debugged from the Java IDE, GWT gives you the ability to alter the output of the GWT compiler. You can select from two levels of verbosity ("pretty" and "detailed") that will emit JavaScript code that can easily be mapped back to the Java source. Once you have your "pretty" or "detailed" JavaScript, you can easily insert debugger commands to be picked up by a JavaScript debugger. You could use this verbose version of the JavaScript code when you deploy your application to production, but it is usually desirable to use the default mode of the GWT compiler, which is to compress the code as much as possible.

At another level, GWT has a powerful concept called Generators, which effectively auto-generates code for you (GWT itself uses them for its RPC, i18n, and JUnit integration approaches). Generators do get a hook into Log4J style log levels, and when running hosted mode or compiling for web mode you can follow the compiler decisions that led to the generation of code you are using - this leads to an easy way of debugging that, for example, could detect that GWT hasn't picked up the latest locale you added.

We have never had any problems debugging a GWT application - and don't forget, unless you are trying to do something really at the edge of the underlying technology (DOM, HTML and JavaScript), using GWT lets you concentrate on debugging your application logic rather than on browser differences.

The other benefit of GWT is of course the use of a strongly typed language - which reduces the probability of introducing errors in the first place. In our development experience so far, there has only been one occasion where we've had to drop down to JavaScript debugging - and that was really to understand what Opera was doing under one particular circumstance with the underlying DOM!

The tools story for GWT is really incredible, especially if you are already a Java developer that relies on these tools. People often quote the saying "GWT brings AJAX to the tools, rather than tools to AJAX" and tools like Eclipse, NetBeans, Ant, Maven, JUnit, and CruiseControl are all usable for GWT development. There is even a visual editor called GWT Designer from Instantiations that allows you to visually design interfaces the same way you might design a Swing, SWT, or JSF application. Tools like GWT Designer started appearing almost immediately because of existing code and knowledge about writing Java tools.

Then there are the best practices. There are reams of literature written on best practices for object-oriented and Java development. Books like the Design Patterns book by the "Gang of Four" and Refactoring by Martin Fowler can be applied to GWT development. Some of the patterns described in these books can also be applied to JavaScript, but JavaScript lacks things like interfaces and abstract classes, reducing the applicability.

It really is not all about just substituting one syntax with another, together those benefits above have been shown to lead to more maintainable code and make team development easier - otherwise we'd all still be writing all of our applications in assembler - and ultimately these benefits will drive down the cost of web applications/allow more complex applications to be built.

Yes. Assuming the developers for a given project know both Java and JavaScript, the differentiating factor will be the size and complexity of the project. If a few lines of JavaScript will do, then GWT is overkill. For small applications, perhaps a few dozen to a hundred lines of code, the JavaScript code will usually be as maintainable and will be smaller than the equivalent GWT code.

Where GWT really shines is when the application consists of many controls, requires passing complex data between the client and server, or if you want to package widgets and utilities for reuse.

Similar to the scripting language vs. Java debate we expect that there will be some JavaScript developers that couldn't imagine a JavaScript application that was too large to not be maintainable. One of us was a Perl developer in a former life, so we understand the draw of scripting languages, but Java clearly has some advantages for writing larger applications - modularity, easier to implement common design patterns, type safety to name just a few. There is also still a need for deeply technical JavaScript developers - it is possible to envisage times when GWT compiled JavaScript may not be fast/compact enough in the the way that people still occasionally write in assembler; as well as the Open Source nature of GWT should attract these people who are interested in making GWT tighter and even more optimized than it already is.

Its been hinted at a few times in our answers, but one way of thinking about the GWT versus JavaScript debate is the same way the debates from the 1960's and 70's over assembly versus the emerging higher-level languages were resolved. The higher-level languages "won" due to maintainability and reliability of code - which all goes to reducing the total cost over the lifetime of the project, an issue that web 2.0 projects cannot hide from for too long - however, segments of assembly are still used from time to time when it is needed.

If you were using the web in the late 1990's you will probably remember those animated GIF files of the mailbox that everyone used on their web pages to indicate a mailto link. So many sites used those animations because they thought that animations in general were cool. It wasn't about what the web user needed or usability, it was about using the latest cool toys. The same happened with framesets, DHTML, applets, and every other new technology on the web. Undoubtedly the same will happen with some early GWT applications, particularly as new releases of GWT add new widgets and panels there will be a tendency to throw everything in that there can be.

The point is that you shouldn't alter your expectations based on the tool. GWT is a solution to writing web applications with demanding user-interfaces, and should only be employed when it will help you deliver what your users actually need. So the answer to your question is no, a real-world GWT application is not bloated, assuming you use it when appropriate. We really like GWT, but as a developer you can't just use a technology because you like it.

When it comes to amount of code generated by GWT, it helps to understand how the compiler works. If you use Java you will be familiar with some of the utility classes like Vector, HashMap, Date, and others. When your code is compiled to JavaScript from Java, so are all of these classes that you used (or are used by other objects you used) in your project. So if you used Vector, your compiled code will include the JavaScript equivalent of this class.

This can result in a lot of code as you might expect, but the GWT compiler does some additional work to make it lean. The compiler starts by stripping out methods that don't actually get called. So if you only use two methods of a class that has ten methods, the code for the eight unused methods will be stripped out. The compiler then makes any other optimizations that it can to reduce the code size further. After that it takes what is left and renames all of the methods and variables to as few letters as possible, so a method doStuff() might be renamed to aB() to make the physical size of the code as small as possible.

Except in very small applications this will result in smaller a file size than the JavaScript equivalent. To give you an example, one of the most popular JavaScript libraries is scriptaculous (which makes use of Prototype) results in over 100K of library files. This is a hefty size penalty to pay if all you want to do is use one or two animated transformations. GWT on the other hand will only include the code that you actually need, then compress it, resulting in a smaller JavaScript file. This allows third-party GWT libraries to be bigger and do more without adding a size penalty for unused code.

We singled out scriptculous purposely because many GWT applications include animations often provided by scriptaculous. There are currently a couple animation libraries in the works written specifically for GWT, including one in the works from ourselves. We love scriptaculous, but all of that JavaScript is bigger than we like.

The Dashboard application that comes with the GWT In Action book contains around 1.12Mb of GWT code. The resultant JavaScript code is on average 245Kb - 22% of the source code size. Whilst 245Kb might sound large, this is an application that breaks our rule above since it packs in as much of GWT as possible into one application! Oh, and did we mention that GWT compiled code is specifically created to allow it to be compressed by the server? With compression, the 245Kb file could be as small as 60-80Kb.

GWT is also taking approaches to reduce load-time bloat, and release 1.4 introduces image bundling capability where you tell the compiler that these 10 separate images can be bundled together as 1, cutting down the return server trips and then splitting up the image on the client side as needed.

We think that targeting JavaScript was the right choice. It all comes back to the compiler. If you target Prototype or Dojo you now have the overhead of that library as well. Because the GWT compiler targets the lowest-level available in the browser, it can also make optimizations that wouldn't otherwise be possible.

This is a common misconception. A GWT application can mix Java and JavaScript code through the use of the JavaScript Native Interface. It lets you hook in JavaScript code similar to how a traditional Java application would use JNI to hook in compiled C binaries.

In fact, some of the first third-party classes distributed for use in GWT were wrappers to popular JavaScript libraries. Both of us are contributors to one of these third-party distributions, the GWT Widget Library (http://gwt-widget.sourceforge.net/). The GWT Widget Library contains Java wrappers for scriptaculous, JSCalendar, JSGraphics, and TinyMCE, and other JavaScript APIs such as Google's AJAX Search functionality.

In fact, you may have also heard of Google Gears, the new off-line AJAX tool with a JavaScript interface. There is already a GWT interface that uses JSNI so that you can use Gears from Java.

So no, GWT isn't crippled, in fact it has access to all JavaScript libraries, plus all GWT libraries. Of course writing natively in GWT allows the compiler to perform its magic and factor out unused code and remove most of the browser checking code that other JavaScript libraries have to include.

There are two issues that pop up recurring on the related GWT forums regarding lack of Java features. Firstly, it is easy to forget when coding in Java that you are targeting a web application. Hence there are often questions about why java.io or the JDBC libraries are missing/unable to be compiled by GWT. They are missing, and rightfully so, since client side code resides in a web browser which cannot do these things either - the solution is to use them as with any web app on the server side. Secondly, Java 5 syntax is not currently possible on the client side - it is in the pipeline for being implemented, but is not really a crippling aspect.

In general each of the approaches aims at addressing DOM, XmlHttpRequest, and other differences and we have to agree that the common ones are all quite successful in achieving this. Where GWT adds an advantage is in how it achieves hiding the differences. The secret sauce is the GWT compiler.

In a pure JavaScript approach you will use some code to detect the browser being used, and then execute the JavaScript appropriate for that browser. This is a simple solution, and easy to implement, but it generally means you need to send all the code for all browsers across the wire but only use part of it.

In GWT you need to do a little extra work to manage browser differences, but there are additional benefits. GWT's approach requires creating multiple Java classes, one for each variation. The DOM class of GWT is a great example of this and demonstrating how to cope with both hiding the differences and leveraging of the object oriented approach of Java. There is a basic implementation DOM class that contains most of the functionality, then additional classes extend the basic class providing only the variations needed for a particular browser/family. You therefore have a very nice set of classes in a well defined hierarchy which is easily maintainable and extend-able, compared to an approach that contains lots of "if browser= IE do X else if browser=Opera do Y......" spread over a number of places.

The payoff for all of this extra work, is what the GWT compiler does with these classes. Instead of creating a single JavaScript file it will create one file for each browser, and each JavaScript file only contains the code required for that browser (and further optimized to only include code for methods actually used). GWT uses some small, around 8K, bootstrap code to load the appropriate file for the browser you are using. The goal is to keep each JavaScript file as small as possible.

If you think only about the small browser differences, for example XmlHttpRequest, then this seems like wasted effort, and if that was the use case GWT was trying to solve we would agree. Where this really makes big difference is when browser differences result in a lot of additional code - take a look at the DOM class and think of the future issues of maintenance libraries that do not use this approach will have. Consider an application that needs to use either VML or Canvas for drawing, or Google Gears for off-line storage only if it is available. Your own code can harness the same approach - why send all the <embed> and <object> code necessary for all browsers just to display a Flash movie when you can send just the appropriate one?

To take this a step further, GWT applies this same approach to internationalization as well. So the German version of your application only includes the German vocabulary, the Italian version includes Italian, etc. For each permutation of browser/locale the GWT compiler will create a new JavaScript file.

Granted, this can result in a lot of files, but in practice it doesn't cause any issues. Fans of JavaScript may balk at the number of files GWT generates, but this can really help keep the size down providing for a better user experience.

The answer probably breaks down into two parts - more controversially, 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. Of course that is a generalization, but developing a substantial web application is not as simple as just adding a scriptaculous effect to a DOM element.
Changing locale is sometimes sighted as an issue as that requires a round trip to the server to select a complete new JavaScript permutation - however, in the real world users are less likely to be changing locale at the rate you do in testing, so the overhead required is not as poor as it sounds. If for your application this is an issue, then you can fall away from the static i18n approach preferred by GWT to a dynamic approach using the GWT Dictionary class - in doing this you lose GWTs ability to strip out unused code.

A modularization framework is something that would be useful to have natively supported in GWT. As it stands, you need to load all of your application in one go, so if you have 5 application modules they all are loaded when the web page is loaded. In certain cases being able to download modules individually as needed would be beneficial.

Yes the book does cover 1.4. The final version of the book was sent to the printers just before the 1.4 release candidate was finally released, but since GWT is Open Source we had access to the source code and the developers list during its development. So we took the risk of updating certain chapters so the readers didn't need to buy the second edition straight away!

Aspects of 1.4 that are definitely in the book are the approach to Image Bundling [Ch4 on Widgets], how the loading mechanism has changed (and how that plays nicely with the old way) [Ch17 on Peeking into how GWT works], the small changes to JSNI [Ch7], the additions to internationalization and talking about how the Serializable interface is now available in addition to IsSerializable. We don't go into detail on the new widgets (e.g. SuggestBox/Rich Text Editor) or panels (e.g. DisclosurePanel/Splitters) within GWT 1.4, but that fits with the way we have written the book as an "in Action" style rather than a rote reference.

Technorati : ajax, google, gwt, interview

agile ajax

Comments: 11 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   But should application developers be building the UI too?

   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.

   Comment by alek, Thursday, June 7, 2007 @ 1:20 pm

2. 

   I must admit, as a server-side java developer being thrown into this whole 2.0 javascript client side world for a particular project, I initially thought that GWT was a great idea.

   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.

   Comment by Andrew Morgan, Thursday, June 7, 2007 @ 2:24 pm

3. 

   People just need to learn javascript. I can’t believe how many people like gwt. Thats like saying, I managed to make my gas motorcycle be pedal powered. People don’t realize that javascript is a very powerful language with useful inheritance patterns (although different) At least you don’t have to say
   if (”string”.equals(variable)) {

   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.

   Comment by Ryan Stout, Thursday, June 7, 2007 @ 2:41 pm

4. 

   The comments miss many of the points I cover in my GWT Demystified compiler article on my blog (http://timepedia.blogspot.com)

   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.

   Comment by Ray Cromwell, Thursday, June 7, 2007 @ 4:04 pm

5. 

   Regarding Mixing Development and Design: This is an area that could use some improvement, however, it’s not nearly as bad as you paint it:

   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.

   Comment by Reinier Zwitserloot, Friday, June 8, 2007 @ 6:47 am

6. 

   @Ray Cromwell:

   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.

   Comment by alek, Monday, June 11, 2007 @ 9:52 am

7. 

   It amazes me that a year after GWT has been released, so many people discard it as a stupid idea without knowing much about it. It the most powerful AJAX toolkit in existence. Bar none. Of course you can do everything in Javascript that you can in GWT, that would make sense since it is itself Javascript. People also assume that because you’re coding in Java you can’t let the designers do all the CSS and HTML magic that they always do. I can tell you from experience that you can, and it’s great.

   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.

   Comment by Rusty, Wednesday, June 13, 2007 @ 6:52 am

8. 

   Two errata: “make it’s use infeasible” should instead read “make its use infeasible”, and “have just finish their first book” should instead read “have just finished their first book”.

   Interesting article!

   -P.

   Comment by P. Sam, Sunday, March 9, 2008 @ 2:19 pm

9. 

   No doubt GWT provides some serious advantages to developers such as debugging and client browser abtraction. But, if you’ve ever tried an AJAX framework such as TIBCO GI that provides true abstraction between display and data (not just CSS formatting), you really start wishing there were a way to combine the strengths of the two approaches.

   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.

   Comment by Michael Beeson, Wednesday, April 2, 2008 @ 1:21 pm

10. 

    Nice article. Software projects in my eyes have two absolute goals… firstly, deliver working software to the end user as quickly as possible and secondly, deliver a maintainable codebase. (’working’ can be taken to encompass easy to use!)

    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.

    Comment by Stuart, Sunday, June 22, 2008 @ 4:01 am

11. 

    After my first major project using pure GWT (I even tried GWT-Ext but removed it and wrote the needed widgets myself using GWT code) I agree with Stuart’s comment.

    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.

    Comment by MPS, Thursday, June 26, 2008 @ 5:05 am

Leave a comment