In his post, Henrik gives his opinion on the pros and cons of AngularJS, and you can tell he feels pretty strongly about it because the cons are much longer and more detailed. I’d like to offer my comments on some of those cons, including my original doubts and how those doubts have evolved.
Henrik’s first concern with Angular is that developers run the risk of gaining skills that are very Angular-specific and not easily translatable to other contexts:
My first reaction to this point was to ask, How is that any different with any other framework? I believe that any time you use a framework to build an application, you’re going to have to learn and use some skills that apply to that framwork only. You can’t abstract away forever.
None of these things is necessarily bad (especially the dependency injection). But I can see the risk of becoming so ingrained with “the Angular way” that you don’t know how to do things outside of an Angular app.
I myself resisted learning Angular for a long time. I got wowed by demonstrations at conferences like a lot of people, but I didn’t want to put serious effort into learning how to develop with the framework, I think because 1) it’s trendy, and I have a natural resistance to trendy things; 2) it’s backed by Google, which I have a bit of a … distaste for (more on that in a future post, possibly); and 3) I didn’t want to change, Backbone being my first love in the world of JS frameworks.
Obviously, none of these reasons are good excuses for not expanding my skills and trying my things. I also realized that a lot of companies use AngularJS for their apps, so if I want to stay relevant, I at least have to learn how to use it. So lately I’ve been learning what I can.
Turns out, I think Angular is pretty dang cool. It’s amazing what you can create with very little setup and configuration. I’m also really interested in the Ionic Framework for mobile apps, which integrates tightly with Angular.
So is learning Angular worth it? Most definitely. But I want to be careful not to let that be the only way I know how to develop wep applications.
2. Separation of Concerns
I have gone back and forth on this issue a lot. Henrik says that Angular violates the principle of separation of concerns because of its HTML directives:
In Angular you spend a lot of time describing behavior in HTML instead of JS. For me personally, this is the deal breaker with Angular. I don’t want to describe application logic in HTML, it’s simply not expressive enough because it’s a markup language for structuring documents, not describing application logic.
I totally felt the same way at first. When I saw those
ng-click directives, I thought, How are those any different from the
onclick HTML attributes that are so looked down upon nowadays?
There’s at least one big difference, actually, and that is that the expressions inside Angular directives are always contained within the scope of their controller, whereas the
onclick attribute operates within the global scope. The whole concept of scope in Angular is pretty cool.
1 2 3 4 5
The jury is still out for me on this one. I think both sides make valid points, and I guess what really matters is which approach helps you accomplish the task more effectively.
No doubt about it, AngularJS has a lot of magic. That’s what makes it so great for demos. Now some people in the programming community will tell you that magic in a framework is a great thing, while others will say it’s a terrible thing. Henrik seems to lean toward the latter camp:
Magic comes at a cost. When you’re working with something that’s highly abstracted, it becomes a lot more difficult to figure out what’s wrong when something goes awry. … I would guess most Angular users lack enough understanding of the framework itself to really feel confident modifying or debugging Angular itself.
1 2 3 4
But as Henrik says, magic comes at a cost. When there is so much happening for you automatically, you have to wonder how much functionality you’re including that you don’t actually need, which could be a drain on performance. Angular is increasingly separating out its functionality into modules, though, so that may become less of an issue.
Even more to the point, the more magic your framwork provides, the easier it is to remain unaware of what goes on under the hood, making it harder to tailor to your specific needs and harder to optimize. This point goes along with the first one, in that all this magic increases your reliance on the specific framework you use.
That isn’t to say that you should avoid any magic or abstraction that frameworks provide (in fact, Henrik makes this point later on in his post). Frameworks exist to make it easier for us to develop better applications more efficiently. They also make it a lot more fun (and Angular is definitely fun to work with). But too much abstraction can be a danger because, in Henrik’s words, “when you veer off the beaten path, you’re on your own.”
Conclusion: Have I Gotten Anywhere?
I think I’ve proven the premise of the title of this post—I’m just not sure how I feel about AngularJS. It has been fun to learn and explore, certainly. And I think it’s important to understand how to develop applications with it on some level at least. Angular obviously isn’t going away any time soon. More and more development teams are turning to it, and if I want to be a part of some of the cool work that is going on, I’m going to have to speak the language.
Perhaps not surprisingly, at the end of the post I’ve been referring to, Henrik discusses a new framework created by the people at &yet called Ampersand. Of course they’re going to favor their own creation, but I’ve been looking at Ampersand the past couple days, and I have to say, it is pretty cool. It’s like the new generation of Backbone. I will certainly have more to say about it in a future post.
Until then, keep on learning and keep on coding!