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.

However, these points also ring true:

“2. There were quite a few GWT books during the beginning. Not so much these days. “

You have to use online resources almost exclusively if you are coding for GWT.

“3. GWT is not fun to work with. After all it is Java and Java is not a fun language to work with…”

I appreciate the caveat! It is true that creating a UI with GWT is nowhere near as fun as hacking Javascript and HTML.

If you are about to start a user interface project and are comparing projects, check out Ganeshji’s blog and see which pros and cons fit your situation.

Links:

• GWT – Pros and Cons

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

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.

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.

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.

If you recall, at Google IO 2009 we got Ray Ryan’s talk on MVP, the SafeHTML API was announced, and numerous other changes which helped real-world development (code splitting, cell widgets, the list goes on…) were declared to be part of GWT 2.0 — and it was clear that many of these changes would not have made it into the toolkit had Google Wave not needed them so desperately. In short, GWT 2.0 was a great release.

Because of the frustration Dhanji and his team suffered during the development of Google Wave, which I believe was real and reflected issues we also had with the toolkit at the time, the Google community received an enhanced toolkit which I continue to believe will allow us to deliver fast, rich, and – perhaps most importantly – maintainable internet-based applications well into the future.

Links:

• Dhanji’s post
• Google Wave launch at Google IO 2009 (video)
• One blog post extolling the many great new features of GWT 2.0

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.

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.

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

• 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)

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 and serialize it into the page before it is sent to the user; then each portlet could initialize itself using data already present in the page rather than making adding an Ajax call to the queue. Updates could be done via Ajax, but the initial page start time would be much more impressive.

Even if this behavior is a limitation of the OpenSocial architecture, the same solution can be applied to almost any Ajax-based application — including those written using GWT. We are moving closer to having an easy method of serializing initial data into the pages containing Ajax applications, and we should take every opportunity to replace “startup” or “init” Ajax requests with the data we would have pulled in with those requests already injected into the page.

Ajax is a great improvement over form submission, but if we ignore the opportunities that the old ways still offer us we will have only made a half-step forward.

How many Ajax calls do your pages make after they load in the browser? How many could be merged, or removed entirely by pre-populating the results in the page containing the application?

Links:

• Pat Niemeyer’s now-classic “Simpler and Speedier” post