A Management View - Why AngularJS Should be Your UI Framework of Choice

A number of people have asked me to explain, from a management POV, the excitement around Angular. Is it something a few techies find intriguing ... or are there solid business reasons to "go Angular"?

What questions should managers consider when evaluating a development framework?

Management Wants

1. Can we create a "complex" web application at a predictable cost? 
2. How quickly can we on-board new members to the project team?
3. How can I arrange work so I can have a reasonably sized team work on the same project at the same time?
4. Can I have the same level of quality / test coverage as I expect on my java and .NET projects?
5. Will the system reach a point where the next change will break it? I.E. Can I count on it being extended at a reasonable cost in the future?
6. Can I count on the framework itself being supported and available 5 years from now?

Don't Consider Angular for Trivial UI features

Before we can start answering these questions, let's look at the scenario where we should even consider Angular.

The trends for web sites is that they have to look, feel and respond like an application. They have to work on a phone, tablet or a desktop application (preferably with 1 code base). This means writing code that will execute largely inside the user's browser.  (So if you have

browser-resident systems are a challenge. Browsers, which have to host the application, vary widely in their capabilities.  Over the past 10-15 years, we've seen 3 low-level standards emerge.  The programming language JavaScript has squeezed out almost everything else.  The objects on the web page (DOM) are governed by the HTML5 standard.  Styling and animation are dictated by CSS3.  But all these are low-level standards.  Think of them as the raw materials in building a house. They alone are not enough to make a complex structure that will meet your goals.

When we say "complex", we're talking a web application that is more than some animation on a web page, or a widget.  For that, use some JavaScript library.  Complex?  Let's look at a UI application with a number of views, that could cost hundreds of thousands, or millions; a system that is tied into a range of web services. Now, we're talking serious corporate money.  You need a framework.

Crying for a Framework 

The raw materials (HTML5, CSS3 and JavaScript) are like the raw materials to build an office building ... steel, wood, plaster, wiring, plumbing, HVAC. What is missing is structures that guide and organize our use of the raw materials, and the teams that work on the project.

Let's look at a series of options for a web application framework.

Option 1 : No framework. You can give these raw materials to your development team, and say "go at it". All well and good.  We don't have to worry too much about on-boarding ... all we need is people who know about the raw materials. Unfortunately, we will have no certainly on our other issues: team efficiency, quality and cost.  And what will we end up with?

Could you build significant office tower with nothing but raw materials?  With experienced people? Maybe.  Will it be efficient and effective?  Probably not.  Is it repeatable?  Doubtful. As seemingly absurd as this option is, many organizations take this approach!  Their techs argue "It is more efficient".  God bless!

Option 2: Toolkits  The late 2000's gave rise to a large amount of open source tools, libraries and widgets to organize the raw materials.  These toolkits extend the raw materials to make common tasks easier.  jQuery is the most popular library, but there are literally dozens, all appealing to various subsets of needs.

These libraries can simplify common tasks and dramatically shorten the time it takes to stand up applications.  Some, like Backbone and Knockout have gained popularity for specific purposes.

However, most of these kits focus the developer on the manipulation of the DOM (objects on the web page).  Testing is hampered, and as the web page changes, tests break or are abandoned.  The net: you can't have many people working on the same application, and your tests will rarely be extensive.

Option 3: The Application Frameworks: Aren't there JavaScript frameworks that will give us the design discipline of Java Spring or .NET MVC?  After all, the MVVM / MVC approaches have a lot of non-raw material practices that encourage SOLID systems.  Aren't there any that supports such an approach in JavaScript?

Angular is that framework.  While we're not making the definitive argument here for Angular over all others, Angular does satisfy management's wants:

1. We can create a complex web application with some degree of predictability.
2. With the right architectural approach (a strong MVC / Services architecture) , as we advocate, you can start newbies right away, with having to wait for them to grok the whole framework.  Like MVC & Spring, Angular has a significant learning curve.
3. But with an intelligent separation of concerns in an MV* design, you can have many people working on the same project, on the same web view, at a time. And by dividing concerns, you can add a new person to the project in a "sandbox", where they can be productive in the 1st week.  We've done it!
4. Testing is a first-class citizen in Angular, meaning you should be able to get 80%+ code coverage for your JavaScript code.  Compare that to any toolkit or to "raw materials" developers.  I think you'd be lucky to see and maintain a 25% test coverage.
5. With the MV* discipline, the system will not exhibit a high degree of brittleness as it grows ... as a jQuery application is very likely to do.  The costs of adding a new extension will be significantly lower.  Why? Because Angular allows you to maintain a strong separation of concerns.
6. It's supported by Google, and is the most popular JavaScript framework. True, Google could withdraw its support as the community expands. But, that is a stronger vote for longevity than some toolkits supported by 2 or 3 guys in a far-away land.

Caveat

So those are the arguments for a framework like Angular.  

However, most of the benefits you'll derive come from the discipline of the team in following an MV* pattern.  Few blogs, web-sites and API docs on Angular suggest this.  But that is the same for Spring or .NET MVC.  It's not the framework, it's the skill and experience of the team using the framework.

So, if you made the choice for Angular, and did not follow any patterns, you'd end up with a "pattern free" system, and far fewer of the benefits described.

The team who is experienced at good design will soar with Angular.

Should you "go Angular"?  If you have the talent, it's a resounding yes.