Problems with Angular
Since its initial release in 2010, Angular has remained one of the most popular frameworks for client-side SPAs. Apart from bringing MVC to front end development, Angular's two-way data binding keeps data models constantly in-sync with their views. This allows for true data encapsulation and reduces the need for DOM manipulation.
Despite such advantages, libraries like React and Vue have quickly given the original Angular a run for its money. Through emphasizing unidirectional data flow (flux) and the shadow DOM, these competing libraries have proven much faster than Angular 1. Even Angular 2 (a complete rewrite of Angular 1) uses components and flux architecture to better harness change control and improve performance.
Does this mean Angular 1 is dead? After all, why would any developer choose the original Angular when libraries like React and Vue have caused the Angular team to completely rewrite their own framework? If React has proven faster than Angular, why even bother? In this article, we discuss the pitfalls of Angular 1 and the viability of using it in today's world.
Problems with Angular 1
While two-way data binding is a cornerstone of Angular's appeal, it's also the basis for Angular's pitfalls. Angular's two-way data binding is made possible through its digest cycle, a recursive check of every $scope variable or watcher in the DOM. Every time a user event occurs (click, keydown, etc), Angular checks each watcher for changes. For any change, Angular registers the event and re-checks the DOM once more for more changes. This is how Angular keeps views constantly in sync with their underlying data models.
Although this digest cycle works great with a limited number of watchers, things can get messy fast when your application grows. Even Angular recommends no more than 2,000 watchers for any particular page of your app. While this may seem like a lot, you can quickly surpass this number with directives like ng-repeat that add watchers for each iteration. When you consider the fact that Angular must recursively check every watcher for every event, it becomes obvious how quickly performance can become an issue.
What makes React better?
React (and other popular alternatives including Angular 2) follows the flux architecture, which relies on unidirectional data flow instead of MVC. With flux, UI components simply "react" independently to change events as they occur. When a user event occurs, a dispatcher broadcasts payloads to registered callbacks. These callbacks are linked to stores, which React components (controller views) retrieve state and respond accordingly.
The main advantage of this flux architecture is that components only update when necessary. This is a huge improvement over Angular 1. Rather than recursively checking each variable or watcher on the page, React only updates what needs to be changed. Angular 2 follows this same flux architecture.
React and Angular 2 also make use of a virtual DOM to compare state changes. Rather than redraw every DOM element, React compares the virtual DOM to the real DOM and only redraws elements as necessary. While constantly generating a virtual DOM may sound inefficient, it is a much more efficient way of updating/redrawing DOM elements.
Is Angular 1 Dead?
While the pitfalls of Angular 1 are apparent, the framework is still widely used. Not only have a plethora of existing apps already been written with Angular 1, there is also a rich community of developers and documentation to support it. Angular 1 also has less of a learning curve than React or Angular 2, which rely heavily on preprocessors and TypeScript, JSX, etc. It is much easier for a JavaScript developer to jump into Angular versus React/Angular 2. Additionally, if you are aware of Angular 1's pitfalls you can design your app to minimize known issues. This includes minimizing watchers, avoiding nested repeats, paginating large data sets, etc.
Conclusion
The original Angular still has a place in today's world. Whether you are maintaining a legacy app or starting anew, Angular 1 can still be considered a viable option. Just be aware of the alternatives and what they are doing to address the pitfalls of Angular 1. This will give you a better idea of what NOT to do with Angular 1 and will better prepare you for the future of client side development.
