Slashdot Mirror
GWT in Action
Michael J. Ross writes "Server-side computer languages, such as Java, possess numerous advantages over their client-side counterparts — including more robust integrated development environments (IDEs). In contrast, Web-focused languages, such as JavaScript, benefit from the global accessibility of the Internet. Bridging this gap, and leveraging the strengths of both sides, has long been an objective of the software development community — though not all attempts have been successful, e.g., Java applets. The Google Web Toolkit (GWT) is the latest attempt, and shows considerable promise, as illustrated in a new book intended to help programmers learn this new technology: GWT in Action." Read on for the rest of Michael's review
GWT in Action
author
Robert Hanson and Adam Tacy
pages
600
publisher
Manning Publications
rating
6
reviewer
Michael J. Ross
ISBN
1933988231
summary
A practical introduction to programming with the Google Web Toolkit (GWT).
Written by Robert Hanson and Adam Tacy, this book was published by Manning Publications on 5 June 2007, under the ISBNs 1933988231 and 978-1933988238. For any prospective reader who would like to learn more about the book, they can first try the book's Web page, where they will find online versions of the "about this book" section, table of contents, preface, and index. The publisher offers two freely downloadable chapters, "Creating the Default Application" and "Communicating with GWT-RPC," in PDF format. In addition, there is a link to purchase the book's electronic version, and a link to the author's forum, where readers can post questions about the book or GWT, and likely receive a response — perhaps even by one of the authors.
The book's 17 chapters are organized into four parts, and cover a generous number of topics: introduction to GWT; creating the default GWT application; building your own application based upon the default one; creating widgets and panels, including composite panels; processing user events; creating JSNI components; modularizing your code; communicating using GWT-RPC; client-side RPC; classic Ajax and HTML forms; using JSON for interoperability; automatically generating code; GWT's native properties; testing and deploying GWT applications; more on the inner workings of GWT itself. The book has no appendices, but a substantial index, which is essential for such a technically detailed subject area.
GWT in Action is clearly intended to be a practical and fairly comprehensive coverage of Google's new toolkit. Almost all of the GWT concepts are explained within the context of developing a substantial sample application, the Dashboard, created by the authors. The reader is encouraged to follow along as the authors build the application, thereby learning from doing — almost always an effective approach. At 600 pages, with almost none of the formatting padding found in far too many technical books nowadays, the authors have not skimped on providing the reader with a lot of information. Furthermore, their treatment of application deployment is far better than any other I have encountered.
Unfortunately, the book has many weaknesses. On an overall basis, the order of presentation is at times disjointed — seemingly dictated more by the Dashboard and less by the most logical order for someone new to GWT. Compounding the problem, the authors frequently refer to advanced topics, covered in greater detail later, and also repeat earlier information, occasionally several times. Despite promises to provide a gentle exposition, it can be difficult at times for the reader to determine if any critical steps were skipped, as a consequence of key instructions for building the sample application being spread out, and interspersed with too many references to general comments covered earlier. In turn, readers will likely find it frustrating to try to get the sample application working at each step of the development process — and not just at the end, with the complete code.
One source of these difficulties, is that in the first few chapters, the authors try to introduce too many topics all at once, and as a result do not thoroughly discuss each one in its own section. Instead, they break up the information over multiple sections, scattered throughout the book. An example of this is internationalization. Section 2.2.4 is titled "Implementing Internationalization," and yet provides almost no details, and is essentially unusable by itself. At the very least, it should mention that later sections 3.2.1 and 15.3 provide a lot more information. Furthermore, internationalization was introduced far too early in the book, and greatly complicates the process. Instead, the authors should have created a simple application using only English for the user interface, and introduce internationalization later, after fully explaining the basics of turning Java code into JavaScript functionality.
Part I of the book is the weakest of all of them, which may, sadly, turn off readers who would otherwise get to the better material later. The authors are clearly enthusiastic about the topics at hand, and the number of moving parts associated with Java/JavaScript/GWT development is certainly not trivial. Nonetheless, those initial chapters would greatly benefit from a rewrite; this would make the material more comprehensible and easier to follow, step-by-step.
We can mention some specific flaws: A book like this that is introducing a new technology, must take care to not leave the unwarned reader wondering if they have been left behind in the steps. People reading some of the earlier material may conclude that those steps have already been assumed by the authors, and will not be covered. The authors do not mention how to obtain and install GWT until page 30; that should be right up front. The authors do not appear to mention which version of GWT they used for the book. (I chose 1.3, not 1.4RC, available as of this writing). Any reader trying to follow along and implement their example application (the Dashboard) will probably find several hurdles. First of all, make sure that you have version 1.4 of GWT installed, and not 1.3.3, which does not include some of the panels and widgets used in their sample code.
In Chapter 1, they modify a "Hello world" application to create another application that shows a tic-tac-toe board that has clickable squares, but does not play the game. Chapter 2 describes this as "a fully functioning Tic-Tac-Toe application," which is like claiming a program works because it compiles. Also in Chapter 2, their discussion of development alternatives is slowed down by repetition of the same information. The sample code in the book has minor inconsistencies. For example, naming a password String "oldPass" in one method, then "old" in another, related method. There are other instances, but these give one an idea of some of the inconsistencies.
The coverage of topics is generally quite thorough, though at times verbose and redundant — particularly in Chapter 2, though it is certainly not limited to that chapter. The second and third paragraphs in Chapter 3, for instance, continue the repetitious style which is found in many places throughout the book, and likely has made it longer than necessary. In Chapter 4, the first two pages explain what widgets are, several times, and conclude with a picture of a button — as if any reader who has made it that far into the book doesn't know what a button is. The book could certainly use some trimming.
The downloadable source code is not complete. For starters, it is missing the code from Chapters 1 and 2, though admittedly none of that is too long. The code provided for Chapter 4 is just a portion of what is displayed in the book. Moreover, the directory paths in the sample code archive files, are not consistently named, and some may even be incorrect. For example, the code for Chapter 5 has a folder named "Dashboard — Chapter 4." That sort of thing does not instill confidence in the typical reader. The authors should revisit the sample code — making it complete and consistently named.
The publisher's page for the book does not appear to have a link for errata; perhaps none have been reported yet. Here are some: On page 75, in Table 3.1, in the left-hand column, "gwt-onLoadErrorFn" should instead read ""gwt:onLoadErrorFn." On page 77, in the second paragraph, the file name extension should be all lowercase, not all uppercase. On page 78, in Listing 3.6, the String parameter in the first label.setText() call should be delimited with straight quotes, not curly quotes. (Microsoft Word strikes again?!) On page 81, in the third paragraph, "comply to" should read "comply with." On pages 87 and 88, the -whitelist and -blacklist option values each contain an extraneous space before the "^." There are undoubtedly more such errata throughout the book, and can be corrected in the next edition; but these are enough to at least get an errata file started. Fortunately, none of them would lead an alert reader astray.
Even though the book could use significant reorganization and streamlining in the next edition, GWT in Action is packed with practical information on a wide range of GWT topics.
Michael J. Ross is a Web developer, freelance writer, and the editor of PristinePlanet.com's free newsletter.
You can purchase GWT in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The book's 17 chapters are organized into four parts, and cover a generous number of topics: introduction to GWT; creating the default GWT application; building your own application based upon the default one; creating widgets and panels, including composite panels; processing user events; creating JSNI components; modularizing your code; communicating using GWT-RPC; client-side RPC; classic Ajax and HTML forms; using JSON for interoperability; automatically generating code; GWT's native properties; testing and deploying GWT applications; more on the inner workings of GWT itself. The book has no appendices, but a substantial index, which is essential for such a technically detailed subject area.
GWT in Action is clearly intended to be a practical and fairly comprehensive coverage of Google's new toolkit. Almost all of the GWT concepts are explained within the context of developing a substantial sample application, the Dashboard, created by the authors. The reader is encouraged to follow along as the authors build the application, thereby learning from doing — almost always an effective approach. At 600 pages, with almost none of the formatting padding found in far too many technical books nowadays, the authors have not skimped on providing the reader with a lot of information. Furthermore, their treatment of application deployment is far better than any other I have encountered.
Unfortunately, the book has many weaknesses. On an overall basis, the order of presentation is at times disjointed — seemingly dictated more by the Dashboard and less by the most logical order for someone new to GWT. Compounding the problem, the authors frequently refer to advanced topics, covered in greater detail later, and also repeat earlier information, occasionally several times. Despite promises to provide a gentle exposition, it can be difficult at times for the reader to determine if any critical steps were skipped, as a consequence of key instructions for building the sample application being spread out, and interspersed with too many references to general comments covered earlier. In turn, readers will likely find it frustrating to try to get the sample application working at each step of the development process — and not just at the end, with the complete code.
One source of these difficulties, is that in the first few chapters, the authors try to introduce too many topics all at once, and as a result do not thoroughly discuss each one in its own section. Instead, they break up the information over multiple sections, scattered throughout the book. An example of this is internationalization. Section 2.2.4 is titled "Implementing Internationalization," and yet provides almost no details, and is essentially unusable by itself. At the very least, it should mention that later sections 3.2.1 and 15.3 provide a lot more information. Furthermore, internationalization was introduced far too early in the book, and greatly complicates the process. Instead, the authors should have created a simple application using only English for the user interface, and introduce internationalization later, after fully explaining the basics of turning Java code into JavaScript functionality.
Part I of the book is the weakest of all of them, which may, sadly, turn off readers who would otherwise get to the better material later. The authors are clearly enthusiastic about the topics at hand, and the number of moving parts associated with Java/JavaScript/GWT development is certainly not trivial. Nonetheless, those initial chapters would greatly benefit from a rewrite; this would make the material more comprehensible and easier to follow, step-by-step.
We can mention some specific flaws: A book like this that is introducing a new technology, must take care to not leave the unwarned reader wondering if they have been left behind in the steps. People reading some of the earlier material may conclude that those steps have already been assumed by the authors, and will not be covered. The authors do not mention how to obtain and install GWT until page 30; that should be right up front. The authors do not appear to mention which version of GWT they used for the book. (I chose 1.3, not 1.4RC, available as of this writing). Any reader trying to follow along and implement their example application (the Dashboard) will probably find several hurdles. First of all, make sure that you have version 1.4 of GWT installed, and not 1.3.3, which does not include some of the panels and widgets used in their sample code.
In Chapter 1, they modify a "Hello world" application to create another application that shows a tic-tac-toe board that has clickable squares, but does not play the game. Chapter 2 describes this as "a fully functioning Tic-Tac-Toe application," which is like claiming a program works because it compiles. Also in Chapter 2, their discussion of development alternatives is slowed down by repetition of the same information. The sample code in the book has minor inconsistencies. For example, naming a password String "oldPass" in one method, then "old" in another, related method. There are other instances, but these give one an idea of some of the inconsistencies.
The coverage of topics is generally quite thorough, though at times verbose and redundant — particularly in Chapter 2, though it is certainly not limited to that chapter. The second and third paragraphs in Chapter 3, for instance, continue the repetitious style which is found in many places throughout the book, and likely has made it longer than necessary. In Chapter 4, the first two pages explain what widgets are, several times, and conclude with a picture of a button — as if any reader who has made it that far into the book doesn't know what a button is. The book could certainly use some trimming.
The downloadable source code is not complete. For starters, it is missing the code from Chapters 1 and 2, though admittedly none of that is too long. The code provided for Chapter 4 is just a portion of what is displayed in the book. Moreover, the directory paths in the sample code archive files, are not consistently named, and some may even be incorrect. For example, the code for Chapter 5 has a folder named "Dashboard — Chapter 4." That sort of thing does not instill confidence in the typical reader. The authors should revisit the sample code — making it complete and consistently named.
The publisher's page for the book does not appear to have a link for errata; perhaps none have been reported yet. Here are some: On page 75, in Table 3.1, in the left-hand column, "gwt-onLoadErrorFn" should instead read ""gwt:onLoadErrorFn." On page 77, in the second paragraph, the file name extension should be all lowercase, not all uppercase. On page 78, in Listing 3.6, the String parameter in the first label.setText() call should be delimited with straight quotes, not curly quotes. (Microsoft Word strikes again?!) On page 81, in the third paragraph, "comply to" should read "comply with." On pages 87 and 88, the -whitelist and -blacklist option values each contain an extraneous space before the "^." There are undoubtedly more such errata throughout the book, and can be corrected in the next edition; but these are enough to at least get an errata file started. Fortunately, none of them would lead an alert reader astray.
Even though the book could use significant reorganization and streamlining in the next edition, GWT in Action is packed with practical information on a wide range of GWT topics.
Michael J. Ross is a Web developer, freelance writer, and the editor of PristinePlanet.com's free newsletter.
You can purchase GWT in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
(Disclaimer: I evaluated GWT and decided that it was cool for larger web apps, but for a smallish website I think it is overkill. So.. I'm not a GWT user, sorry.)
When I was developing my site (which you will visit now and purchase lots of album downloads), I had to deal with the fact that browsers do not implement things consistently. In particular, IE seems to do things differently than every other browser. The idea of GWT is to do all the hard browser bug workarounds and compatibility work for you, so that you write some code in Java and poof! Your web app will look and behave the same across all browsers everywhere. Among the downsides, you have to learn GWT of course, and your resulting code is almost guaranteed to be less efficient and slower to load than if you just code directly in Javascript/HTML/etc.
In the end, I ditched GWT in favor of simplicity, dealing with IE issues as they arose (my native development platform is Firefox). Then again, my site has very limited functionality. YMMV.
david
BitWorksMusic.com -- odd tunes for odd times
I would like to point out that the GWT can also be used from a Java server application. I'm using a package from Instantiations, WindowBuilder Pro, that can generate Swing (default Java GUI), SWT (IBM/Eclipse GUI) as well as the Google Window Toolkit. It's an application/plugin for creating graphical interfaces, so you would probably not get too exposed to the GWT itself. I haven't yet tried it out, but it might be a good idea to start of with a GUI builder and only delve deeper when needed. Of course, understanding what happens is great when you need to debug something, or if you are not happy with the functionality. But I would not start off by writing web-pages when trying out this relatively new technology.
Before somebody grills me, the version of WindowBuilder Pro that I am using is a bit unstable and crashes Eclipse now and then. Lots of memory is also recommended (then again, if you are a developer, you need lots of memory anyway).
Well, i've avoided writing web stuff for my whole career but when I got lumbered with a project at work I used GWT.
Firstly, I had loads of problems. However they were mainly down to broken stuff in the RC builds (all fixed now that it's out of beta) and the fact that I was learning Java as I went along. Nothing that was a major problem was down to the architecture of GWT.
If i'd have written pure javascript instead then doubtless it'd have taken far longer and worked less well.
GWT rocks for anything where you need to write anything with a rich web gui and a large amount of interaction between this and a backend. I can use Eclipse to single step through my Java code, with breakpoints and all that stuff. GWT also takes all the browser specific hassles away, for example with the differing rich text area implementations used by all the browsers. Without these niceties i'd have given up on web development before i'd even started.
Oh and the google group for GWT is great - i've had problems answered within ten minutes. The Google team are very visible and are obviously proud of their product. Rightly so, too.
Languages don't have performance characteristics. They can't be faster or slower than each other. Only implimentations of languages are faster or slower. For instance, the mozilla implimentation of javascript is very slow, rhino is not as slow, but still slower than the official implimentation of python, and most other reasonable language implimentations. I am not aware of any javascript implimentation that comes even close to the performance achieved by high performance implimentations of pascal, miranda, scheme, or common lisp, much less languages with very fast implimentations like ocaml, C++, C, D, etc.
The content on Google's GWT site almost speaks for itself concerning the power of it, so I'll elaborate on some negative aspects I've encountered.
I went to explore the possibility of a non-servlet based backend and very quickly encountered problems that are not really GWT's fault but a side effect of having a hosted environment: the browser is based on Mozilla and thus inherits the security restrictions of it. I could not make RPC calls to my backend web server because Mozilla disallows cross-domain access. I spent a lot of time trying to circumvent this, and did find some work-arounds but nothing that worked to my satisfaction (too cumbersome). GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml file in the root of the target webserver (to see whether access is allowed or not).
Also, developing on an AMD64 based Linux I discovered that the hosting environment just doesn't work running from a 64bit JVM. Setting up a 32bit JVM isn't that difficult, but it's not a good solution (However, I talked to a GWT developer on IRC who claimed this issue was high on their priority list).
Lastly, GWT is a nice environment, but it's still a bit young. It seems stable enough, but if you engage in a large GWT based project you may find yourself doing a lot of low-level client-side code unless their limited palette of widgets and other client-side features completely cover your needs
Not. Java doesn't have closures. Java functions aren't first-class objects.
JavaScript, OTOH, isn't typed.
There's loads of differences between them. All I'd want from JavaScript is more performance, namespaces, and possibly some very basic native OO concepts so that I can define an inherited class without three or four declarations and maybe have private and static members.
...following the principles of Heisenburger's Uncertain Cat...
I agree with you that Javascript is a nicer language than Java and more powerful to boot, but I'm using GWT for one big reason: dead code elimination. The GWT compiler takes advantage of the static analysis possibilities in Java and the closed-world nature of a web page and produces dramatically optimized Javascript. The resulting code is obfuscated, which reduces download time, and has all the dead code eliminated, which reduces download time. Also, for broken interpreters, like the one in IE, a smaller script executes faster, on top of downloading more quickly.
I guess what I'm saying is that GWT brings a compiler to Javascript and that has many benefits. For the GWT compiler, Java is to Javascript as C is to assembler in a C compiler. Generally speaking a C compiler produces better machine code than someone writing assembler by hand. The same is true for the GWT compiler--its output runs faster than a comparable programme hand-written in Javascript.
Ian
Sorry to hear it doesn't work for you. A little OO-obsessed though? Because the framework takes a stance to actually try to provide a real OO programming model where other frameworks simply don't?
I agree that there is a lot to say for simplicity. Especially if your problem is simple. However, my experience is that model 2 just doesn't cut it. I shudder to think back to the horrible instances I've seen of code duplication you get when you can't properly reuse widgets and the tons of hacks I've seen to get around the statelessness of web applications. And then scripting in templates, making them hard to sync with changed designs/ hire a designer to work on them and simply hard to track where logic is put in the first place. I don't know about you, but I never had much fun refactoring JSP and Velocity templates.
Wicket focusses on OO as that facilitates reuse and lets you better cope with complexity. Wicket enforces clean templates so that you won't get yourself into maintenance hell. But it may or may not work for you. It does for me and many others, but so many people, so many tastes. In the end it is a trade off that can be annoying in the short term, but should save you trouble in the long run.
If what you are trying to do fits the request/ response paradigm, that's fine. I for one, prefer to reason about screens that have panels, forms, fields, tabs and buttons on them, and I don't want to rewrite half of my pages just because I decide to put a wizard in a tab, or move a pageable list to another page or whatever.
If you can use Ajax all the way, a simpler approach like using HTML + JS and maybe DWR should work fine, though a library like GWT should help you avoid all those nasty browser issues etc, AND let you write strongly typed (maintainable) code.
I looked into GWT a month or two ago. From what I understood, you can write both client and server code in Java and then GWT compiles the client to Javascript and the server to a servlet.
You don't actually write any SOAP code, but rather use Java Remoting to call across the wire, getting a Java object back that you can manipulate. The GWT compiler translates that into a XML request and writes all the serialization/deserialization code and so on. In fact it doesn't seem to be able to call an XML web service at all (that's the reason why we didn't pick it up for our UI, our company does business logic in C#).
Since it is also a widget library you should be able to have complex widgets with multiple DOM elements and access them as a unit. You could write your own javascripts objects to access the DOM, but then it's basically a GUI library.
As far as I can tell, the whole point is to write both client and server with a single language and interface, which is very useful.
For example, in our case, the pages are generated with ASP.Net in C#. If we want to disable a button when the page is served we do buttonSubmit.Enabled=false; but if we want to reenable it without a postback, we have to add javascript code to find the DOM node for the button and then enable it. Imagine how messy it gets when you want to add a row to a datagrid. After a while you can't tell all the interactions in the GUI handling logic. I'd love to have something that allows me to write an event handler where I can just write "buttonSubmit.Enabled=true;" and let the compiler work out all the DOM walking code.
So you have three choices:
- Serve the full page (formatted in server side language) and then tweak it in javascript, relying on knowledge of the widget library's rendering.
- Serve a bare bones page and do all the GUI in Javascript, both initial and updates. Let the server handle business logic only. I see some posters have suggested moving the initial javascript rendering to the server.
- Serve a full page and let something like GWT convert the client side code from working with the same objects as the server to a working Javascript/DOM implementation. This is the approach GWT is taking.
Of course, I only looked at it for a couple hours, so someone will probably tell me all the ways I'm wrong.
My major gripe about GWT ist the use of Java, which I never liked.
...
So I want to give oyou two pointers to projects that could need help to transfer the idea of GWT from Java to Python and Ruby:
Python: pyjamas - build AJAX apps in Python (like Google did for Java).
Ruby: Blog Entry from Michael Neumann, who tries to port GWT to Ruby.
The Ruby stuff is in the very early stages
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel