Super important* Angular opinions

I’ve been working with AngularJS for almost two years now. Both the framework and how you write apps with it have changed a lot. Angular’s big and I don’t know everything, but I’m comfortable saying I can write Angular applications well.

I also generally like using Angular. That’s not fashionable in the Javascript world right now, but it’s also not an uncommon opinion. Angular has a large, positive, and enthusiastic community. But it’s worth remembering that its usage is a blip compared to the sites with jQuery or even the sites using Backbone. Whatever hot new Javascript thing is currently taking up space on HN is even less of a blip. Maybe one of those things will become the bigger blip, but not without another newer, cooler thing coming along that you should definitely already be using.

All that said, Angular’s not perfect, and with Angular 2 coming up, I want to lay out the strengths and weaknesses so I have a base to start from when evaluating it. These points are not particularly unique and there are easy to find, popular posts detailing most of them.


  1. Testability. This is my favorite thing about Angular, maybe weirdly. It’s not particularly difficult to mock parts of your application and write useful, isolated tests. It can be difficult to set up in a large complex application, but writing the tests themselves works well. A lot of this comes from dependency injection, which while not a common Javascript pattern, is a useful software engineering pattern that I really like in our application.
  2. Two-way binding. Yep. Maybe I’ll get over this. It’s still useful and it still saves time for me. I understand why it’s fallen out of favor, though, and I’m interested to see if I can leave it behind.
  3. Directives. Don’t worry, this shows up in the second list, too. They’re powerful and they allow you to think in components (with some caveats), which makes for clearer code. Also, I really like attribute directives. I’m interested in learning how people adapt to not having them in something like React.
  4. Comprehensive. Frameworks vs libraries is an interesting debate. But it’s really a debate about who is building your framework: you or someone else? Where I’ve used Angular, the fact that it’s a framework built elsewhere is a positive. A large group of developers of varying experience levels trying to sort through a collection of libraries glued and hacked together is not a productive environment. A framework where people can read docs and Stack Overflow questions to figure out how something should work sounds much less stressful to me. Angular has felt like a good balance between the freedom to build company specific patterns and conventions and having a base framework where knowledge transfers from one product to the next. And ultimately, I work for a company building a product. Our developers are building features that solve problems for customers. Building our own special framework is not a customer goal and we don’t hire for it. And if we did? It would be even harder to find the people we need.
  5. Performance. It’s good enough. I’ve run into serious performance problems once, so far. And the primary reasons were garden variety web performance issues: the page design made assumptions about use cases that weren’t correct and we were not careful with the amount of data being sent to the browser and displayed. Sure, Angular wasn’t amazing there and we made some changes (adjusting our use of one-way binding and when to use ng-if vs ng-show), but the framework wasn’t keeping us from meeting our requirements.


  1. Modules. I have not once felt like these were useful. They are something you use because you have to. I’d much prefer to be left to do this myself as much as possible.
  2. Directives. See, told you. We all know the issues here. The directive API is awkward. Sure, the parts are understandable, but it’s too much. And while controller-as is a step forward and everyone should use it, it’s difficult to explain and justify to those just learning.
  3. The digest loop is magical and opaque. I’m not a huge fan of calling things “magical.” It often means “abstraction I don’t feel like learning about.” But I think it applies here. It’s confusing, it has gotchas, it has performance quirks.
  4. Build stack. Libraries like Browserify and Webpack are fantastic. But the starter build process, used by the Angular Yeoman generator? I want to fire it into the sun. It’s not maintainable (a giant list of scripts in an html page?). It pushes you towards a completely static front end, which is not realistic (I started feeling the need for a server rendered index page before I’d even finished my first app). I wish I’d switched to Browserify sooner. And I didn’t even mention minification.
  5. Factories, services, values, and constants. Where I work we really just use factories (that we call services). And constants (which are feeling less and less necessary to hook into DI). We don’t really need Angular to tell us what sort of entities we should use in our apps. We can figure that out on our own. Angular’s choice to go with dirty checking plain Javascript objects saved us a lot of boilerplate. I can write services in Angular that are just business logic that works with normal objects. But then we have these unnecessary object types to stuff everything into. I just need a way to register things with the DI engine. The rest of it makes me feel like a Java developer.

There are other things I like about Angular. The community is large and great. I think the docs are pretty good now. The learning curve isn’t easy, but it’s not ridiculous. But those are more subjective and more likely to be ad hoc justifications for a technical choice.

Does Angular 2 solve these problems? It definitely solves some of them. But that evaluation is for another day.

*Not actually super or important.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.