Technology, Continued...

Ramblings about business, technology, development and my life

NAVIGATION - SEARCH

Why you can use AngularJS (or not)…

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.

https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99

This article comes on the heels of another very similar one from October about what’s wrong with AngularJS.

https://medium.com/este-js-framework/whats-wrong-with-angular-js-97b0a787f903

Better minds than me have already talked about the October article.  Here are Dan Wahlin and John Papa’s responses.

http://www.johnpapa.net/why-does-there-have-to-be-something-wrong-with-angularjs/

http://weblogs.asp.net/dwahlin/what%E2%80%99s-%E2%80%9Cright%E2%80%9D-with-angularjs

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.

Dependency injection

Ok, so he doesn’t like the syntax and flexibility that Angular offers. Fair enough. But the technology itself is fine. Angular is an opinionated framework. He doesn’t like the opinion. But I have found uses for the difference between service and factory before, even if 99% of people never will. If someone wants to use one or the other all the time, they never need to concern themselves with the other options. But they’re there if you need them. As for syntax specifically, they worked around a problem with javascript minification and gave multiple ways of doing the same thing. More power to them. It doesn’t make Angular worse.

Debugging

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.

Scope inheritance

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

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

With a well-written application, it’s pretty easy to look at controllers and services and see what they’re doing. And then you can look at the view and see how the properties in the scope are being used. I’m not sure what’s so hard about that. And as for the server developer understanding what’s going on with the front-end, well, that depends. If your server developers are coding in javascript, they’ll have no problem looking at the controller and service code on the client. If they’re not versed in javascript, or they don’t understand how two-way data binding works, they might have an issue. But I’m not sure how this is different than with any other framework.

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.

AngularJS 2.0

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.

The 1.x version of Angular will continue to be developed.  It will be a while before 2.0 hits mainstream usage.  Don’t *not* use Angular because a new version with breaking changes will at some point arrive.  Frameworks must evolve like this or they will die.  This is true of Angular or any other framework you might choose today.  Compare Angular 1.x to the other frameworks available today and decide if it serves your needs better (for you) than the others.  If it does, run with it and enjoy whatever benefits it gives you.  Oh, and of course all of this is open source, so your company will never be abandoned or your app obsoleted as long as you can write and change javascript yourself!

Summary

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.

Comments are closed