Read Insight

Why I recommend Angular 2

If your web app is built on Angularjs, why not switch to Angular 2 if it can make your web app 5x faster? Here are four reasons why I’d recommend Angular 2 for developers building new web applications or planning to upgrade old apps to new frameworks.
1. Performance (speed)
2. Mobile device support (native app like experiences)
3. Component based (modularity and reusability)
4. Typescript and Ecmascript (ES6) support (clean and structured code)

Performance (speed)


The most important factor of any web application is “performance”, specially in case of web applications that have complex UI, rendering large amounts of dynamic data. Watch Listener is an important capability Angular offers to constantly check if there are changes in data and if there are, load the new data without page refresh. Angular 2 compared to Angular 1.x, offers a much faster and smarter way to automatically detect data that is continuously changing and respond to it swiftly, without hindering the user experience on the web page.

Manual Watchlists in Angular 1.x Vs Auto detection & triggers in Angular 2

Responding to change in data is much slower in Angular 1.x and here’s what makes it so. In Angular 1.x, $scope assign a value to variable, creates watches (to listen to change in data). Many such watches result in a watchlist. When the value in $scope is modified to a new value, a digest cycle takes place. Every digest cycle will have a minimum of 2 iterations because the first iteration will watch (check) for any change in $scope and second iteration will be performed to make sure that there are no watches in the 2 iterations. Chances are that the value modified by one watch may also modify the value modified by another watch, in the meanwhile. After one complete digest cycle, the UI gets updated and renders the DOM. This may not be a problem with simple UI, however in case of a complex UI, it takes more time to update the DOM, which results in slow performance.

In Angular 2, detection of change is done automatically by making use of Zone.js and it triggers change (like $digest in Angular 1.x). Asynchronous operations like events, http requests, timers cause the state to change in our application. Zone.js makes use of the concept “Money Patch” i.e., replacing a member function (and related functionality) on any object with a new one. Zone.js obstructs all of the asynchronous APIs in the browser (when Angular runs). This is the reason why we use setTimeout() inside our components rather than something like $timeout because setTimeout() is monkey patched. Angular 2 maintains change detector for every component / directive. It keeps track of the state of all of your bindings, for dirty checking. These are similar to $watch in Angular 1.x for template bindings. Change detection graph traverses from root to its leaves. It is a unidirectional directed tree and cannot have cycles. When an event is triggered, event handler callback runs, updates the view and renders the DOM. Since Angular 2 follows a unidirectional tree structure, it provides improved performance than it’s previous version.

To summarize, if I were to build a web application for stock market enthusiasts that deals with a lot of data every minute or let’s say a web application that counts people falling sick every minute indicating patterns – I’d do it on Angular 2.

Mobile device support (native app like experiences)

AngularJS 1.x was not built by keeping mobile devices in mind. We could achieve it using frameworks like Ionic. But, this requires additional learning curve and may also affect the overall user experience. Angular 2 has been designed with mobile in mind, it is designed to offer extensive support for mobile devices where touch events and gestures work across all devices.

  • Angular 2 supports Single (Universal) Framework for both Web and Mobile device which reduces learning curve to most of the developers.
  • Angular 2 has great mobile features like touch support, low memory, material design UI elements and performance tuning etc, which will help quickly resolve mobile related issues.
  • We can build a native application for android and IOS with the help of Angular 2 & Nativescript 2.0. We can reuse the same code what was written to build the web application.

Component based (modularity and reusability)


In Angular 1.x, we have controllers and scope. In Angular 2.x, there are no controllers & scope, they’ve been replaced with Components. Components enable the code to be highly modular and reusable.

Another big plus point of moving towards Component – based apps is that it will be easier to define Interfaces. Also the HTML elements already have an easily mappable interface in events, attributes, and properties. This is the reason why the code is more testable, because of the exposed behaviour of the component.

Technically, Components are directives that are always associated with a direct template. Here’s how a Component works:

Step 1: Import the component
import { Component } from ‘@angular/core’
Step 2: Add metadata to component using typescript decorator.
selector: ‘my-app’,
template: `


This metadata tells Angular 2 how to process a class
Step 3: Export the component.
export class AppComponent {
componentName: ‘AppComponent’
Step 4: Bootstrap the component.
import { bootstrap } from ‘@angular/platform-browser-dynamic’

Typescript and Ecmascript (ES6) support (clean and structured code)

Angular 2 has been built using Typescript (superset of javascript), which I see as the future of web application development, because of its object oriented properties such as class, interfaces etc., along with the support of Ecmascript(ES6) which helps in handling complex application logic and building them.

There is high productivity with Typescript because of its cleaner ECMAScript 6 syntax and optional typing. TypeScript makes code easier to read and understand than plain javascript. You wonder, how?

Eg: jQuery.ajax (url, settings)

Here we know exactly, its takes 2 parameters for sure. First one may be of type string and second parameter is of type configuration object. But, this is just a guess and that might be wrong too. We have no idea what data go into the settings object.

There is no way we can know settings object without checking the source code or the documentation. Checking the source code is not an optimal way to find it. We can check the documentation, but it is not the best developer experience and it takes additional time. One should be able to pick functions and classes for reuse, by just looking at the definition (eg: interface definition) not the implementation.

Learn more about us, our vision, our experience and what we could do for you.