Making the Most of Angular - WebINTENSIVE Software
single,single-blog,postid-17652,ajax_fade,page_not_loaded,,,qode-child-theme-ver-1.0.0,qode-theme-ver-6.5,wpb-js-composer js-comp-ver-4.4.3,vc_responsive



Oct 21, 2017 Making the Most of Angular

An earlier post explored the utility of the Angular framework, particularly when creating “single page application (SPA)” Web apps. That article also noted some of Angular’s drawbacks. Today’s post is a conversation with Arun Saini, VP Technology at WebINTENSIVE, exploring just a few of the many steps WebINTENSIVE’s team has taken to minimize those shortcomings and draw greater value out of Angular than is available “out of the box.”


Q: It’s fairly well recognized among software engineers that Angular is challenged when working with a large amount of data bindings—relationships between data. Why is that, exactly?

A: That’s due to the way Angular performs change detection. Out of the box, AngularJS scans through the entire object model looking for object bindings that may be impacted by a change to an object. This strategy was carried forward in later releases, though it was mitigated somewhat.


Q: Mitigated but still an issue. Did the team take steps to help Angular perform even better when many data bindings are needed?

A: That’s right. It still wasn’t enough for some data-intensive interfaces, so we delved into the nuances of how Angular functions. We use this knowledge to take its “On Push” strategy and integrate Redux state management along with a proprietary library for managing immutable JS objects to drive performance to the next level. Angular 2 and Redux integrations aren’t commonly available in the community.


Q: Do you take that approach with all SPAs?

A: No. We actually only use this strategy judiciously: only for pages that have a certain number of data bindings. We revert to Angular’s internal strategy elsewhere (for lighter pages) where our improved strategy would have been overkill. Careful consideration is needed to know when to use our enhanced approach—and when not to.


Q: How can components be reused quickly and cost-effectively?

A: We created an approach to do this efficiently. Everyone builds Web applications using a component-based approach since AngularJS 1.5+. That continues today with Angular2. The difficulty comes when different applications need slightly different behavior or different visual appearances through use of different themes. We carefully analyzed a method for building truly reusable components that require little to no rework when integrating with different applications. We used parameterized data injection to let users modify/customize component behavior at run-time. We also separated the template from the behavior to allow easy “theming” by independently updating the HTML and CSS templates without having to rework the behavior.


Q: Is Angular always the right choice?

A: No, not always. Angular is a “heavy” framework with a steep initial learning curve. And it doesn’t match the performance level of some other frameworks—ReactJS and Vue for example. So for simpler and smaller applications or when the developers aren’t trained on any framework and speed of implementation is important, it would be prudent to use ReactJS, Vue, or another lightweight framework.


Want to learn if Angular is the right framework for your Web application? Just call to arrange for a chat with one of our specialists.