Defending AngularJS

Jeff Whelpley
3 min readOct 7, 2014

While Angular is not a good choice for all situations and some of your points are valid, there is quite a bit missing from your analysis.

  1. Logic in HTML — While you can (and many people do) put too much logic in your HTML, this is an anti-pattern. Good Angular HTML just contains hooks to your controller and other services where a bulk of your logic should reside. In my mind, an Angular HTML attribute is the same thing as adding a JavaScript-only class to a div element (which how most other JS frameworks hook into the DOM). I prefer the Angular way because it is more explicit, but I think if best practices are followed all the way around, this ends up being purely a matter of taste rather than anything inherently wrong with it.
  2. Two way data binding — As of Angular 1.3 you can use one time data binding. The best practice is to only use two way data binding in specific situations where it makes sense.
  3. Dirty checking — Agreed that on mobile this is an issue, but in most other cases performance is a non-factor (meaning that it is good enough). I also agree that the Flux architecture is better for more complex flows that require precision. The advantage of dirty checking and Object.observe, though, is that it is easier to set up and maintain for more basic use cases.
  4. Duplicated app structure — Not sure what you are talking about here.
  5. Angular performance — I have several fairly substantial client side web apps and have very rarely notice performance issues. However, it is true that something like React is a lot faster which is more noticeable on mobile and for really heavy client side apps. I think this difference will become less apparent in the near future, however. Angular 1.3 has a number of major performance updates, Angular 2.0 will be a huge improvement and as evergreen browsers become more prevalent dirty checking should become less and less of an issue. (edit) I wrote a separate post to cover this topic: Is AngularJS Fast Enough?
  6. Server side rendering — I actually have my own Isomorphic Angular framework called Pancakes.js which does not use Phantom, JSDom or any of those other hacks you are referring to.
  7. Hard to learn — The popularity of Angular is largely driven by the fact that doing simply things is really easy and most people can get something working very quickly. Actually building a legit app is hard and there is quite a learning curve, but I would argue that every large client side framework has a similar learning curve (including React, fyi).
  8. Google using Angular — This point is where you lost me a little. Gmail was built long before Angular existed and has its own custom framework which is much more down to the metal. Angular is used on many projects at Google including big ones like Doubleclick.
  9. Vendor lock — Again, you lost me here. Angular is an open source project. If Google dropped it tomorrow, there would be a huge line of heavy hitters ready to take over ownership.
  10. Angular 2.0 Rewrite — Yes, no doubt it is a pain when there is no upgrade path between versions. Python developers are still struggling with upgrading to Python 3. There is a major benefit, however. You bring up some legit concerns within this article and there are others you have not mentioned like verbose syntax, lack of idioms, missing model layer and crappy router. All of these things will be addressed at some level within the Angular 2.0 rewrite. It would be nearly impossible to do so with iterations on top of the existing codebase. Is it worth the pain? That remains to be seen, but from what I have seen so far, I am inclined to think so.

At a high level, I think the benefits of Angular outweigh the current warts in many use cases and there is every indication that a large majority of those warts will be removed over the course of the next year.

--

--

Jeff Whelpley

Co-founder and CTO at GetHuman, Google Developer Expert (GDE), Boston AI Meetup Organizer, Boston Angular Meetup Organizer, Boston College alumni