A few days ago, I found myself in the position of talking with a team about the benefits we’ve seen using AngularJS in developing web applications. There are so many popular choices out there, React, Ember, KnockOut, Backbone, jQuery, etc., etc. These are all solutions that can help a team build very capable web applications. Is there something that makes Angular stand out from the crowd?

I think so, but before examining those benefits, I do want to emphasize that ultimately, a development team needs to deliver a product. The technology should serve the team. I think Angular does that well, but other solutions may be a better fit for your team, given experience, mindset, project history, or other factors.

Angular covers a good range of functionality for building robust web applications. Wintellect has used Angular successfully on very large enterprise projects, using hundreds of controllers, services, and directives. It worked well for us on a large, distributed team. We saw benefits such as:

  1. A project with a lot of Javascript can quickly become unwieldy, but once a team had good patterns in place, other team members were able to easily replicate these patterns as the application was built and expanded. It became a lot easier to manage this growth. This was due a lot to the good opinions that Angular has about building web applications.
  2. The Angular framework is opinionated, meaning that it has a specific recommendation for how a web application should be architected, but it is a good opinion. It defines nice boundaries for separation of concerns that if followed allows for much more manageable Javascript code. It even includes features for extending functionality (like HTTP interceptors, common exception handling, etc.) that can be used to meet specific application requirements, which allows you to work with the framework rather than trying to hack together a solution.
  3. Angular is a broad framework and there is complexity (especially in directives), but we found that 80% of the time, developers were doing simple common tasks, like implementing controller functionality for model data and event handlers, calling back-end services, and declaring data binding. The more experienced developers could focus on the more complex areas, like custom directives.
  4. Directives were a key feature for a large application. Directives focus on user interface interactions and can be used to build custom, reusable controls. Being able to copy common UI controls and interactions was a huge time saver and maintenance improvement all around.
  5. Angular tends to “fail fast”. It has a lot of safety checks and helpful diagnostic messages that we were able to use to quickly determine how the application was failing.
  6. The interest in Angular has increased greatly (see this comparison of search terms over time, for example). What this means practically for a team is that there is a lot of mind-share around Angular, which means there are a lot of resources to be found. We found that this was a huge benefit when we were dealing with issues in developing with Angular. There are many, many discussions, documentation, tutorials, and videos around all aspects of Angular development. This helped team members get up to speed quickly and improve the overall quality of the development efforts as well.
  7. This is completely anecdotal, but when my colleagues and I were starting to really dig into Angular, there were many times that we had “Ah Ha!!” moments when using Angular. We’d be discussing how best we might implement this or that feature. We would find ourselves thinking “I wonder if Angular would work this way?” And the amazing thing would be that the Angular team had already thought about it and had implemented some feature that allowed us to do what we needed. If we seem eager to evangelize Angular, it’s because of moments like these have really made us fans of the framework.

I also recommend reading this popular post from Jeremy Likness that discusses reasons that web developers should be learning Angular: