How GWT is enabling Blueprint’s agility

October 12th, 2008 Olivier Modica Posted in GWT | 4 Comments »

We deploy a new release of Blueprint to production every 6 weeks and we do this by having a great team, an efficient development process and a best-of-breed technology stack that lets us build the best end-user experience at the lowest long term engineering cost.

GWT is a big part of the Blueprint technology stack obviously, and if you read this blog it’ll be clear to you that we’re huge fans of GWT, are leveraging it as much as we possibly can and have some of the best GWT experts on staff.

I’m not going to debate here whether GWT is a better technology than X or Y but instead I will focus on the features GWT gives us to enable Blueprint’s agility.

Productivity

Thanks to GWT Blueprint is 100% written in Java, end-to-end. While this may not be a huge advantage for small applications, let’s look at what this means for us:

Tools: Java certainly has the best ecosystem for tools, whether it is for authoring (IDEA, Eclipse), code health tools (FindBugs) or continuous build systems (Cruise, CruiseControl, Bamboo, TeamCity). Being able to use those same tools for both front-end and back-end development means more productivity and better quality.

Debugging (hosted mode): you really have to see this for yourself, but debugging your GWT application within your favorite IDE while it’s running in real time in the browser is a killer feature. You can step-over, step-in, change the Java code on the fly (which of course gets compiled into JavaScript as you go)… this is just a huge productivity boost.

Refactoring: with an application as large as Blueprint not being able to refactor the code base on an ongoing basis would lead to a maintenance nightmare and cut down on our ability to deliver on time and with high quality (hence loss of productivity). Because the entire code base is in Java, and GWT takes care of the Java to JavaScript compilation automatically,  we can refactor at will regardless of whether the code is back-end or front-end.

Cross-browser support: as I have come to find out, developing an application for runs and looks great on IE6, IE7, Firefox 2 (Windows/Mac) and Firefox3 (Windows/Mac) is pretty painful. Thankfully GWT does a great job for us here, and while we do have some browser specific issues to deal with this is essentially a non-issue at the engineering level.

Testing

A front-end technology wouldn’t be very helpful in supporting your agility if it couldn’t be tested efficiently, GWT works well here:

Unit testing: you can test your GWT front-end UI code using JUnit very easily, and as explained by Alex in this post you can also test the full interaction (client and server) through JUnit tests. This is huge for us as we can increase our test coverage on an ongoing basis very effectively. All those tests (including back-end and front-end) can be driven by a single continuous build system creating a single build dashboard.

Automated testing: we’re planning a future blog post that will go into details here, but essentially with a minimal amount of changes GWT-based front-ends can be tested through automation frameworks (i.e. Watir, Watij, QEngine) easily. While this was an area of concern when we first moved to GWT, it didn’t turn out to be warranted. Automated testing for GWT-based front-ends works just fine.

GWT maturity

It never hurts to pick a technology that is developed by the great folks at Google, and as evidenced by our relatively painless upgrade to its 1.5 release GWT is well on its way to become a mature technology. The quality of GWT, as well as its open source license and distribution, means that it just won’t get in the way of getting your application completed and in production.

Flexibility of the technology stack

I think it’s important to choose a technology that isn’t so pervasive that migrating to a different, better technology would mean you couldn’t release any new features for a long time. GWT doesn’t try to be too much; it just does a great job for the front-end. This means you can pick and choose various technologies when building your end-to-end technology stack; we use a number of different ones and the relatively small GWT footprint is a clear advantage for us.

The bottom line

Now, that is not to say that GWT is perfect and we certainly have a few features that we’d love to see in upcoming releases. But we’re pretty pragmatic people here, and we try to pick technologies because we have data backing up why it’s allowing us to deliver on better user experience and an aggressive roadmap.

As engineering manager it’s part of my job to ensure we’re always looking at better technologies to improve on what we do; and hopefully you’ll find this post helpful next time you’re evaluating web technologies because passing on GWT would definitely be a shame!