Pros and Cons of Using the Google Web Toolkit

We have had a good rollout of an internal UI framework built using the Google Web Toolkit, and it is a good fit for us — but is it a good fit for everyone?

Ganeshsji Marwaha at the Ganesh blog posted “GWT – Pros and Cons” several months ago, a list which is has gotten some attention lately in the twitterverse and which rang true to me as I read it over.

With 22 Pros and 12 Cons, this list is a good place to start if you are considering using the GWT for one of your projects.

Among the reasons we use GWT:

“2. Even if you are not experienced in Java GUI development, the experience in working on server-side Java for years will come in handy while developing GWT apps”

We are a Java shop, and developing with Java from end-to-end is a huge productivity benefit.

“5. You can migrate from a typical web application to a GWT application iteratively. It is not an all or nothing proposition…”

We have a huge set of products which are built using other approaches, but we have been able to create new products using GWT while incrementally improving existing products with features developed for our new UI framework using GWT.

“14. You have the advantage of being able to use standard Java static code analyzers like FindBugs, CheckStyle, Detangler, PMD etc to monitor code and design quality. This is very important when you are working in a big team with varying experience.”

Static code analysis is a huge boon to quality in large organizations, and being able to run these tools on our UI code has been a big help. Certainly there is an effort needed to custom-tailor rules for GWT (for instance, to enforce specific use of GWT-RPC), but you can use the off-the-shelf rules to check the other Java UI code immediately.

These were large factors when we were deciding to use GWT instead of other toolkits.

Security Training: You Are Not A Special Snowflake

The trend in software security training is towards common, standardized training for developers, according to the software security firm Cigital.  This is contrast to the earlier days of security training which tended to be tailored for specific technology stacks and toolsets.

Per a recent Cigital blog post:

We’ve seen some significant changes in the Training part of the software security market. First, most firms have come to realize they are not a special snowflake when it comes to writing secure code. For years, the vast majority of firms felt that software security training had to be an exact, customized match for their skill levels, their technology stacks, their SDLC, their coding standards, and even their IDEs. It took a while for many firms to understand that the origin of their XSS and CSRF bugs, for example, was probably not their choice of IDE or SDLC, it was rather tied up in how their code was being attacked based on its design and implementation.

XSS issues are XSS issues, regardless of the nature of your application.  This is one reason projects like OWASP can provide standard cheat sheets and guidance regarding different vulnerabilities; ultimately, at the end of the day those of us writing web applications speak HTML and Javascript, and any attack which leverages those languages will affect us all.

Links:

• Software [In]Security: Software Security Training – trends in secure software training and the source of the above quote

The Art of Being Lazy

One of the things I have found I consistently do on the job, regardless of the nature of the work, is attempt to automate the repetitive manual tasks which are common in many environments.

Back in college, when I had a data entry temp job to pay the bills, one of my daily tasks was to take two computer-generated lists and cross off entries that the two lists had in common. This being the green-screen terminal days, opportunities for automation were scarce, but a recently installed Apple Macintosh with green-screen emulation software gave me my first venue for removing the mind-numbing task from my daily to-do list.

At the time I did not know I would make a habit out of being lazy* in this way, but here at GT Nexus I find myself extolling the virtues of Larry Wall-style laziness to whomever will listen.

Continuous integration systems are only tenuously related to my duties as a Software Architect, but they help us all be lazy (which leads to better productivity) and we have been improving our systems consistently over the past year. Static code checkers have been part of our build cycle for years, and we constantly try to improve and tune them to automate our bug detection before our code reaches our testers.  If we need to change a collection of files, scripting — I tend to use Groovy, but there are many options available — is the only way to make it happen. All these efforts pay big dividends over time.

Every day we are doing more to automate our work, whether it is in regard to testing, code review, or development. If I can find a way to automate good design, I will evangelize that as well.

What are your favorite automation tools? Do you do whatever you can to be as lazy as possible?

 

 

* “We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” – LarryWall.  Find more here.

Congratulations to ZeroTurnaround for JRebel Award Win

JRebel is a tool which has saved us uncountable* hours of development time by allowing us to skip the step where we restart our Weblogic servers to test a new feature as we develop it.

The word about JRebel has apparently gotten out, because the developer behind it, ZeroTurnaround, has recently won the 2011 innovation award from JAX awards.

As an early adoptor and frequent user of their flagship product, I am happy to see them take the award home. If you have not had a chance to integrate JRebel into your server-side Java development process, I recommend you try it out.

Links:

Award posting: http://www.zeroturnaround.com/blog/jrebel-the-most-innovative-java-technology-of-2011/

 

 

* They are counted on a per-developer basis, but I do not have the totals for our entire company.

Reflecting on GWT’s Growing Pains

In a blog post reflecting on his time at Google, Dhanji R. Prasanna mentioned in passing that some internal Google projects, including the Google Web Toolkit, were maintained by engineers having no connection to the folks who used them to build shipping products.

Specifically:

“And new projects like GWT, Closure and MegaStore are sluggish, overengineered Leviathans compared to fast, elegant tools like jQuery and mongoDB. Designed by engineers in a vacuum, rather than by developers who have need of tools.”

While I do not work for Google and cannot comment on the actual goings-on inside those teams, from what I see from the outside Dhanji was right on the money for the Google Web Toolkit.

I say “was”, because I believe that the Google Web Toolkit team was focused on delivering more theoretical, and less practical, extensions to the toolkit before Google Wave launched. The Google Wave team wrote their wave client using GWT, and in the process I believe they pushed the GWT team past their comfort zone.  When Google IO 2009 – the venue for the launch of Google Wave – arrived, the GWT team announced GWT v2.0, a huge improvement over previous GWT releases.

Google IO 2011: All About Android (and Chrome)

This year’s Google IO conference in San Francisco was pretty amazing: there were some great announcements, like Android@Home, the Ice Cream Sandwich release of Android, Chromebooks, and more. In some ways the number of announcements (many more come to mind, like the Google Music service) was overwhelming.

On the GWT front, however, things were a little more sparse. Only 4 presentations were what I would call “pure GWT”, although some other sessions, such as “Chrome Developer Tools,” were quite useful as well.

There were no Ray Ryan “Best Practices for Architecting GWT Modules” moments, but that may have more to do with GWT maturing as a platform than any lack of innovation on the part of the GWT team. One team member, I forget who, alluded to this when they explained that in the past the team was driving hard to get the basic Java to Javascript compilation working properly for all platforms; now they are working to implement neat new features from the HTML 5 spec (insofar as they are nailed down) and improving the framework.

My impression is that GWT is undergoing a transition similar to what happened to Java when it went from v1.2 to v1.3.  Version 1.2 (or just “Java 2″) saw a huge improvement in the capabilities and basic language structure of Java, whereas v1.3 added features around the corners and continued the maturation of the platform.  (I must confess that I cannot remember any specific improvements with 1.3, although I must have been excited about them at the time.)

It was reassuring to know that the GWT team is growing, and Google continues to have confidence in it. One related announcement at the conference was that the browser-based version of Angry Birds was written using GWT. No doubt that will be the highest-profile use of GWT anywhere!

In the coming days I will post some specific reflections and notes from the conference, so stay tuned.

Google IO 2011 Right Around the Corner

This year’s Google IO is on May 10-11, in San Francisco’s Moscone Center.  After selling out in less than an hour, Google is planning to support multiple “Google IO Extended” viewing areas around the globe to help spread the presentations and sessions at Google IO as widely as possible.

Looking at this year’s sessions, GWT seems to have a smaller footprint than in recent years; there is still a “performance” talk, but there is also one on game development — which is interesting, but may not help out us enterprise developers as much as, say, Ray Ryan’s 2009 IO talk on Best Practices.

Regardless, we will be going this year, and hopefully the GWT team will have a pleasant surprise or two for those of us pushing their technology into the cloud.

Structuring GWT Modules for Large Applications

Over at the Summa Blog, Ben Northrup has written up a great article outlining difficulties we face when deciding how to partition GWT modules for deployment, as well as the pros & cons of each approach.

I recommend you read the entire article, but here are some of the highlights:

You can structure an application as a single .war file, or as many .war files. Large files will take more time to load and process in the client, but enable you to share state between different product areas; you can use code splitting to help keep the initial load time down. Creating multiple smaller files will keep load times fast, but GWT compile times will grow proportionally to the number of modules you create and the different product areas will not be able to share state in the client.

Here at GT Nexus, we have a large common module which contains our framework classes and custom widgets. We continuously merge in contributions from product teams adding code to be shared, which helps us maintain UX consistency. Each product is currently a single GWT module, however, which required us to do some investigation into methods for reducing compile times. We are developing methods for merging related modules, but the impact to client performance must always be considered when increasing GWT module size.

If you are facing an issue of determining how to partition your application into GWT modules, I strongly recommend you read Ben’s full article.

Links:

• Structuring GWT modules for large applications
• A Few Ways to Get Better GWT Compile Times

Notes from OWASP 2011 Summit Published

While I am a member, I did not attend OWASP‘s conference in Lisbon, Portugal last week. For those of us who did not attend, they have published a summary of the conference, and I found the following initiatives particularly encouraging:

• Mozilla, Google, and Microsoft are discussing common browser security issues.
• OWASP has partnered with the Apache Foundation to help get OWASP code into Apache Projects.
• OWASP projects are being mapped to all major approaches, including Microsoft’s SDLC, BSIMM, and of course the OpenSAMM.

There are more notes, but I feel these are likely to benefit the SaaS community most in the near-term. OWASP is quickly becoming the go-to organization for free and open security information and code libraries, in much the same way as Apache has for other libraries and tools for the last decade and a half.

These developments can only help make all our code more secure, which is good for everyone. I recommend that you take a little time to check out what they have to offer.

 

Links:

• OWASP Summit 2011 Summary (PDF)

Mixing Metaphors: Ajax + Web 1.0 > Ajax

As we continue development of our internal GWT framework here at GT Nexus, I continue to be amazed at the power that using modules written using the Google Web Toolkit within a JSP provides.

Pat Niemeyer gave us a strong clue to its usefulness a couple years ago, but over time it has started to become clear that serializing load-time data within a page containing Ajax code is a great way to improve performance and increase the usefulness of any Ajax-based application.

Here at GT Nexus we use an internal knowledge sharing system which is based on a wiki engine but which also provides an OpenSocial based dashboard, and I am always in awe of how long it takes the dashboard to initialize. The delay is due to each component making an Ajax call back to the server to retrieve its data, which takes time and is subject to the limitations browsers place on the number of outstanding requests.

It would be far better to understand what data is required for each portlet