Making the Switch from GWT to AngularJS

bDill-Angular-BlogPost (2)

28 Apr

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 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.

 But our experience with GWT has exposed some pitfalls. Some of these pitfalls are probably not inherent with 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.

 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.

 

Brian Dill
Brian Dill
Bdill@bandwidth.com

Brian is a Senior Software Developer on the Bandwidth Dashboard Team. Before coming to Bandwidth, he helped create tools for the open source community at Red Hat. He's currently making the switch from creating services on the backend of the software stack to putting together customer-driven web apps. He's probably also the only developer that doesn't like pizza.

6 Comments
  • Emilio Bravo
    Posted at 19:00h, 26 October Reply

    I do not dispute that in your case migrate to angularjs is the best option, but I want to provide a little more information about GWT.

    Goal #1: You can use Twitter bootstrap or polymer with GWT or plain HTML + CSS
    https://github.com/gwtbootstrap3/gwtbootstrap3
    http://www.gwtproject.org/doc/latest/polymer-tutorial/introduction.html

    Goal #2: I understand that you are experts in java, With GWT you can debug java code in eclipse o intellij and logging using Java API. Java stack trace client code errors.

    Goal #3: the same as the first goal.

    Extra: with GWT you can share java code between server and browser, use java libraries and use java build tools like maven or gradle.

    Regards.

  • Carl Pritchett
    Posted at 05:02h, 27 February Reply

    On two large projects I have both reaped the rewards and payed the penalty for use GWT. Without using GWT at the time we did, we would not of succeeded. Both now times have changed and the painfully slow productivity and dependence on the infrequently updated framework makes ongoing use hard to justify. It’s time for direct use of the modern web technologies like Angular, React, Ember etc.

  • Dialed In - The Bandwidth Blog | Happy Birthday to Dialed In!
    Posted at 14:48h, 01 March Reply

    […] Making the Switch from GWT to AngularJS A look at why our developers chose to make a move from using GWT to AngularJS in one of our internal tools, the Bandwidth Dashboard. […]

  • Arnaud Tournier
    Posted at 12:12h, 28 April Reply

    Hi ! Thanks for your article.

    Note that you don’t have to make the switch anymore, thanks to the Angular2Boot project !
    It allows to write full java 8 applications with Angular 2 runtime on the front side and Spring Boot on the backend.

    Please have a look at http://lteconsulting.fr/angular2boot/

    Thanks

  • Antonio Dominguez
    Posted at 21:43h, 28 April Reply

    +1 Emilio Bravo. IMHO there are another things that can be accomplished just using GWT: XSRF security, i18n and l10n, and another of the more important for me: deferred binding

  • Ana Martinez
    Posted at 09:54h, 06 July Reply

    I don’t like pizza either. I am learning Angular.js 2 so it will be fun to see how it goes. Thanks for the article.

Post A Comment