So it seems to be the time of year for Angular bashing. Isn’t that how it always is when a technology becomes more prominent than others (and how long will that last, anyway?)? The latest is this article about why you should not use AngularJS.
This article comes on the heels of another very similar one from October about what’s wrong with AngularJS.
Better minds than me have already talked about the October article. Here are Dan Wahlin and John Papa’s responses.
For the new one about why you should not use AngularJS, here is my (very) short and sweet response to it.
Two-way data binding
You’d have to pry two-way data binding from my cold, dead hands. Yes, you have to be cognizant of potential performance issues. Yes, sometimes you will have to do things to work around specific issues you might run into. I once had to create my own treeview control because another one I was trying to use had too many bindings and was very slow. So I created my own directive that worked for my needs and kept bindings to a bare minimum. You have to develop with an eye towards potential performance issues. But the productivity improvements from Angular’s two way data binding for developers, as well as the SOC between view and controller make this a tradeoff I’m willing to accept. But to just carte blanche say that Angular is slow as a general statement is ridiculous. Many serious, complicated production apps have been built with Angular. It has proven that it performs fine, as long as you keep performance in mind in your edge development cases. But keeping performance in mind is something we should not only do with Angular, but with service calls, with database designs, with third party api integration work, etc. Performance considerations should be a part of a developer’s DNA, regardless of platform and technology.
I also would like to see errors thrown when a binding is broken. And finding the reason for an error in Angular is sometimes harder than it could be. There are tools out there to help, but the debugging story could definitely be improved.
Yep, this does inevitably bite new developers. But frankly you should be declaring your variables in each scope such that a child scope never even tries to inherit from its parent. This is definitely something that needs to be stressed, but once learned it’s not a problem. To me, a bigger issue is that statements like ng-if create a new inherited scope. I can’t tell you how many times that has bitten me (“why isn’t this @#$@# binding reflecting the variable’s new value? – Arghhh”). In hindsight, they could have done this differently, but again, once learned, you’re not even worrying about this and it’s not an impediment to writing code that works well.
Directives are hard. Granted. But they are worth learning. They are a key reason why Angular is so awesome! This is web development as it should be, with reusable components. Microsoft tried a long time ago, and that was awesome, too, even if it was browser specific. And web components in the next versions of the web will eliminate the need for directives. But for now, they’re the only way to create cross-platform reusable UI components, and they are worth learning. Plus, just like so many other technologies we use in various platforms, many times you’ll just be using an OS directive that does what you need and you’ll never have to know how the internals work.
Problems with people
Inability of server side rendering
This argument to me is ridiculous. Angular isn’t built to do server side rendering. If that is something you have to have, don’t use it. It’s an architectural choice. But the vast majority of apps written with Angular don’t need server side rendering. And as mentioned in the article, if you need to provide html-indexable versions of your pages for SEO, there are solutions that absolutely work.
There will be changes. I’m excited that they are looking to learn from the experience with 1.x and improve it in every way. How is this different from most other technologies. I guess we shouldn’t use Bootstrap since they changed things between 2.x and 3.x. Entity framework is out because v7 is re-architected. Wow, no MVC for me because they introduced Razor. For that matter, drop Webforms because MVC was introduced.
It’s a fact of life that technologies at some point get re-architected with breaking changes because 1) new tech becomes available (ES6, for example), 2) experience with the old version has shown room for improvement, and 3) better patterns are invented that make a developer’s life better.
If you don’t like the opinions Angular introduces to application development, by all means, don’t use it. But it’s disingenuous to take your opinions and suggest that all opinions that don’t align with your personal development worldview must be wrong. To suggest that everything about an architecture that has room for improvements is therefore ill-conceived is just narrow-minded. Angular has many areas that can be improved. But for me, I chose Angular over webforms, mvc, jquery, knockout, etc., because, after working with alternatives, Angular was the framework that was best suited to the development projects with with I have been and am involved. If someone works with ember, react, etc., and decides that those are the best frameworks for the project they have at hand, then by all means use those.
The beauty of development, and hopefully part of the reason we as developers are passionate about what we do, is that we have choices. Things are constantly changing and improving. Nothing is perfect, but there are many solutions that are good enough, and most are much better than what came before. Find the framework that works for you, your team and your business owner and run with it. We should all worry more about delivering a solution that works for the business that needs it than worry about the framework we use to deliver the needed solution.