Making the switch from GWT to AngularJS

The first lines of code for the Bandwidth Dashboard were written in June of 2012 as a follow-up to the web service API offering. From there, the application has grown organically with development responding to urgent customer needs and evolving specifications. The app, originally written in the Java-based Google Web Toolkit (GWT), has done its job admirably and has been available to Bandwidth customers for more than two and a half years with 2 million requests served just in the last 30 days.

So why am I convinced that making a move from using GWT to AngularJS is in the best interest of the application, our users, and developers? Let’s consider our current goals for the Bandwidth Dashboard.

  • Make a UI experience that our customers love
  • Develop on a platform that can quickly respond to customer needs
  • Allow graphic designers to easily contribute to our applications

Is our current web application framework a good fit for our goals?

Java, only, for a price

Google Web Toolkit (or GWT) is a toolkit for creating web applications that simplifies two traditionally difficult problems for the typical web services team. How do I make a web app for all browsers and how do I get there without learning a new language? To solve the first, GWT contains a collection of browser-compatibility components that come for free with your application. For the second, GWT provides a Java-to-Javascript compiler that chews up your Java code and spits out a Javascript application. This is the big selling point for most teams. Tell them they can keep writing in Java and they’re willing to try it.

However our experience with GWT has exposed some pitfalls. Some of these pitfalls are probably not inherent in the use of GWT, but nonetheless, we deal with them daily.

  • The Java-to-Javascript compilation is dreadfully slow. It’s “go get a cup of coffee and read the paper” slow. Our current compilation time is nearly seven minutes and it requires 3.3 gigabytes of memory.
  • We maintain too many files. GWT requires many lines of boilerplate code to describe how everything should fit together. This boilerplate code accounts for nearly 50% of the lines in some modules.
  • Graphic designers can’t easily contribute to our applications. With GWT it is difficult for designers to simply provide HTML and CSS files since GWT spreads these resources around the project in different formats.

Given these issues we’ll need to take some significant steps to accomplish our goals. Since we’re already in the process of redesigning the look and feel of the site, it seems a great time for making underlying changes as well. Although we could heavily refactor our application, keeping GWT as our framework, we would spend about the same amount of work, but continue to deal with the shortcomings of GWT.

Let’s go back and look at our goals in detail.

Goal #1: Make a UI experience that our customers love.

We’ve recently introduced tools that will give us much more visibility into what customers like and don’t like.

Here are a few excerpts from an earlier Net Promoter survey about the dashboard:

  • “Too many cryptic error messages.”
  • “Dates should be a column in the results.”
  • “Everything is is in sub menus. it should all be accessible from the home screen.”
  • “None of my orders have gone through easily as the old portal.”

This feedback is essential. It’s specific, actionable, and after we address the issues, the results are measurable. For now, the general consensus is that we’re able to deliver the basic functionality the customer needs to survive most of the time, but we’re missing the mark on usability and intuitive design.

Goal #2: Develop on a platform that can quickly respond to customer needs.

Providing a development platform that can quickly respond capitalizes on developers’ productivity. We want developers to be able to dive into existing code, fix bugs, and add features in as short a time as possible.

Goal #3: Allow graphic designers to easily contribute to our applications.

Reorganizing and reformatting UI assets is a poor use of a graphic designer’s or developer’s time. Allowing designers to deliver standard web UI assets that are immediately usable by developers eliminates an entire step in our workflow.

AngularJS to the rescue?

After reviewing JSF, Dart, Ember.js, and others, I landed on AngularJS as the framework to investigate. It’s a fit for all our goals.

  • Creates responsive applications in a look and feel that our customers are accustomed to seeing
  • Provides simple ways to create and quickly iterate on designs to incorporate customer feedback
  • Consumes standard UI assets

As a bonus, we already have a few Bandwidth teams using the technology for their projects. In addition, AngularJS lives in a rich community of modules and libraries that allow developers to focus on their core business instead of rewriting boilerplate logic.

For a proof of concept, I wrote a simple account listing page. I want to list all of the accounts for our customers in a simple ordered list using our existing REST API.

// chooseAccount.js

// Add a new controller to our application
// Include two dependencies, the AngularJS $scope variable and our AccountService
angularSeedApp.controller('ChooseAccountCtrl', function ($scope, AccountService) {

    // Call the underlying Angular service when the controller loads

    // Provide a function for the page to list the accounts in JSON
    $scope.listAccounts = function () {
        return AccountService.listAccounts();


This example hides the details of the REST call inside of a service, but it shows the basics of an AngularJS controller. The syntax is foreign to Java developers, but once you learn to read it, you can write web application logic quickly. Javascript will never be a pretty language, but it’s possible to write concise, readable functionality if you stick to the framework best practices.

Deployment improvements

We’ve already seen some of the perks we’ll get from using AngularJS, but going forward it could make our overall deployment process much better. Since an AngularJS application is simply a set of static files, we have the option of using simpler and cheaper deployment methods. We can switch from using Tomcat to an Apache HTTP server if we want to keep the servers on-premise. We also have the option of using a static hosting service like S3 to leverage a full CDN solution.

Many AngularJS projects use hosted continuous integration solutions that are built with web applications in mind. Travis CI, for example, handles the testing and deployment aspects gracefully and allows you to deliver more quickly and confidently to your customers.

Going forward

We’ll launch our redesign in a few weeks and the UI development team will begin learning and writing AngularJS code to implement the new application. Though customer feedback will guide us in our design decisions, it’s developer feedback that will help let us know if we’re getting to another important goal: happy developers.