Improving the productivity and focus with AngularJS
Amazing and unexpected results: 1/5 time, 1/3 lines of code, 2.5x productivity, better performance and ☺ users
We’ve just rolled out a major rewrite of the Online Essentials (Avira’s flagship product) in AngularJS. Firstly, OE is a real-time web dashboard. It helps an Avira user to manage all her connected devices & services, focusing on design, ease of use and usability.
The whole idea of this web app is to provide real-time updates & great user interaction. Fast performance was essential, so the decision to be a javascript Single Page Application was a no-brainer. With so many options for implementing this, each of them working best for certain use cases, the decision to choose the best tools was not an easy one.
The reason of starting with Marionette
What are the best javascript frameworks to get the job done?
When the development first started 1.5 years ago (fall 2012), all the usual suspects were taken into account (including backbone and angular). At that time, the backbone community was very mature and Backbone Marionette seemed extremely flexible, with lots of online tutorials about how to build and architect single page applications.
Armed with this knowledge, the team began building the first version of the application using Backbone Marionette, RequireJS, jQuery and Socket.io as the main libraries. Jake was chosen as the build tool (mostly for minification and compression).
12 months later the first beta version was released. After 2 more months, the first version was out for most of the users.
The application was fast, the major downside being the lack of both unit testing and productivity. The team & users were happy with the overall feeling and experience, but we’ve challenged ourselves to do better.
We were spending more time developing the framework architecture than delivering features to our users.
The reason of ending with AngularJS
Meanwhile, a lot of effort was being invested in frameworks like angular and ember. There were already many companies which were using them in production.
We knew from previous experiences with building SPAs (using both angular and backbone) that we can rebuild the entire front-end in angular pretty quickly (1-2 months) with maybe half the code and complete unit test coverage.
Having many built-in features (Services, Dependency Injection, Directives, etc.), angular would make us feel more comfortable building a SPA. It would also give us a better taste about how the future of web development would look like (native DOM templates, web components, 2 way data binding).
We had to shift from building our own framework to building a great app for our big & growing user base and angular seemed to be the right choice.
Backbone Marionette vs EmberJS vs AngularJS
We needed real proof that investing in a fully featured framework would make us more productive and would create more value for our users. It was also essential to invest in something that would allow us to easily test the code.
We started by making the following comparisons to be sure that we would opt for something that has traction and community support:
The data clearly suggests that angular has attracted by far the most interest and community members. It is also backed by Google, who is developing some important products on top of it and it makes a lot of sense to continue investing in it.
For a complete coverage of the features from all major js frameworks, I strongly recommend this article. It sums up extremely well other articles about javascript frameworks written in the past couple of years. It’s also obvious from it that after comparing all features and taking everything into account, there are 2 winners: angular and ember.
In the end, we were confident that we would migrate to a newer and better technology stack so we’ve started the rewriting.
The process went pretty smoothly. We’ve migrated from Backbone Marionette + jQuery + RequireJS to AngularJS, providing all the existing functionalities. We’ve also switched from Jake to Grunt and from plain Css to Less in an attempt to align with the current front-end trends.
UPDATE (May 1st): The initial code base was pretty clean. Most of the code (~ 90%) was only dealing with user features, so the core architecture had less than 2.5k LOC. A rewrite in Backbone M. (given that we already knew where we were heading) using CSS3 instead of JS animations and other code improvements couldn’t have reduced the LOC by more than an optimistic 15-20%, because most of the views had only logic for a specific user feature. Also, writing unit tests was difficult (there was also a lot of DOM manipulation in the views) and this was a key feature we were after. Angular uses a completely different paradigm to solve this. It completely decouples the logic from the DOM manipulation, making testing a lot easier. What patterns and how we structured the code in angular is the subject of a following blog post, so I’d rather jump into the conclusions we have drawn after the angular rewriting.
Results
After we finished rebuilding and relaunching the application (in less than 2 months), we were just amazed by the results:
- improved productivity (>2.5x, given the new velocity score);
- code base reduced by 65% (from 25k to 9k LOC, the code for unit tests not being taken into consideration);
- increased testability (from 0% to more than 70% code coverage);
- increased maintainability (from 66% to 74% as reported by Plato);
- improved performance (decreasing the loading time by 1.5-2 seconds, reducing memory leaks);
- improved debugging (easier, built-in error catching & better reporting).
The numbers are self convincing: the LOC were reduced, the quality improved and the focus migrated towards adding more value for our users (productivity growth) instead of building an in-house framework.
UPDATE (May 3rd): It was easier to measure the performance of each part of the application using the Chrome Batarang Extension than it was before, so we knew what needed to be improved along the way.
The results are as surprising as the rewriting of Google Feedback done by Miško, as a proof of concept for angular, before it was even released in 2010.
Localytics also did a similar rewrite and they were happy with the results.
Conclusions
I consider that a team has to pivot and reconsider its options all the time. A not up to date technology stack can cause many problems, like lack of productivity, performance related issues (when comparing with newer technologies) or just having a hard time recruiting skilled new engineers.
Technologies evolve so fast that not knowing what’s new and how it may help you solve your problem better may make your product be outran by your competitors.
“What we think is state-of-the-art and the most amazing thing right now will be laughable at best or destructive to innovation at worst just a year ahead.” — Christian Heilmann
Big companies (PayPal, LinkedIn, Netflix, Walmart, etc.) are already using NodeJS in production after they concluded that this is the best solution at the moment for their use case. AngularJS and Ember are also being beautifully embraced by the enterprise world. Of course, there is also a lot of wisdom involved in knowing what should be used or not, because not everything may be appropriate for your team / technology stack.
Angular was the right tool for us and it gave us the confidence that we can build and scale a web app no matter how large it is. I recommend any team that is considering Backbone Marionette to also keep an eye open for more fully featured frameworks like Angular and Ember.
