Angularjs and the Mess we are in
AngularJS critique: discover why this powerful framework requires strict discipline. Learn about scope issues, best practices, and when to use Angular vs AngularJS.
Who doesn't know Angularjs?!? Everyone who worked in web, mobile, server, windows, mac, Linux, Google, Microsoft or anything related to this knows about it. And it's fun when people tell me
You know about angularjs. It's pretty hot these days. I'm planning to learn it.
Oh man...
Ok, I am no expert here in Angularjs. And I prefer not to be an expert with any framework. Be it anything. But you know there is another Angularjs from another universe. If you are learning (like seriously) then go for this one.
But be sure. There is a chance you will be inviting a hell of a mess. I have been working with angular since the last 3+ years. Either leading a team or part of a team. And one thing I learned the hard way. You need discipline when you are working with JavaScript. But you need the discipline of delta forces when you are working with angularjs.
As mentioned on the site, it is a superhero. And like every superhero, it also should have responsibility. But angular is abusing JavaScript every way possible. If something is possible, that doesn't mean we should be doing it. We have a damn book called JavaScript: Good Parts all about it.
It's called Good Parts, which means you just use the Good Parts and leave the bad ones alone. But with angular, it is like you are living in a bar and told not to touch alcohol. On top of it, you have Untapped installed on your mobile.
Why this? Let's take things one by one.
Scope - Poor man's global
We should not use globals. That is a proven truth. No doubt in it. But what about we love globals so much?
We got scope then. JSLint can't catch it, and we still have it. Now, angular lovers may argue that we should not use it. But how can you prevent it from being used? It all comes down to putting it as a rule in the project wiki or training. But there is no way to prevent it. At least I don't know one.
Magical Directives
Whenever you start abusing Angularjs, people come up with But we have Directives?!? that magically solve everything. The problem is that it is hiding too much. It's good if things work out, but when it breaks. Oh man. You seriously wish that never happened.
If you still like Directives, try implementing two directives on one element. It will be too much fun. And pure magic if one directive is created by you and the other is created by a third-party.
Three Musketeers - Service, Factory and Provider
I don't know how many times I have searched Google with Service vs Factory vs Provider. Nowadays, you don't even have to put angularjs on top of that. If you write the above message, you will get angularjs answers only. It's way too complicated for a simple module with helper functions. Weren't we all happy with a few base globals in the age of jQuery that were passed in as parameters in modular functions? And now we have DI (proudly called Dependency Injection).
Wired - DI
It is a good thing. A good thing invented from the object-oriented concept. And then it is used almost everywhere, whether it is needed or not. For the case of Angular, it is good that we can have modules without worrying about other modules being directly available in the function. But then what about other libraries? We need to create a wrapper around it to make it the angular way. And then we have plenty of gulp or grunt plumbing tools so you can save your ass when things get minified and combined.
Grass is always green on the other side
I don't say angular is a beast we never wanted. But you need to use it carefully. I have seen more than enough projects, new and legacy, using angular in all the wrong ways. It makes it tough to debug or extend. Every time you get the feeling that you should just dump it all and make it again. We don't need to learn another framework; just learn JavaScript - Good Parts. And things are all good. But instead, most resources are wasted on teaching Angularjs. With the hope that a Super Hero framework will solve every issue we have.
It is not going to be. It was never going to be. It will never be.
We are the ones who are going to solve our issues. Pick your framework wisely and try not to hope so much from it.
My Personal Pick
If I want to be really hard on myself and don't want any errors in my to be big project, I will choose elm. It's not a framework but a hell of a language with crazy html support.
If people are coming from JavaScript land to join me, then I'll go for react.
If there is a need for quick two-way binding on a single page, then knockout is a good thing.
If I want to go fast for a small project and I am the only one working on it, at least for now, or maybe some single person working on it, I will go with Angularjs. I don't mind. It is quick and easy.
Big project? Ember is there. But a few times I feel it is unnecessary complexity. Two-way binding and not much of the angular mess? Aurelia.
Above all, my opinion is derived from my personal experience and is not influenced by anyone. And it is my own.
Frequently Asked Questions
AngularJS is the older version of the framework, while Angular (often referred to as Angular 2+) is a completely rewritten version from a different universe, as the author puts it. If you're seriously learning Angular, the author recommends going for the newer Angular version rather than the legacy AngularJS.
AngularJS abuses JavaScript in many ways and allows practices that shouldn't be used, such as relying on global scope and magical directives that hide complexity. The author emphasizes that just because something is possible in JavaScript doesn't mean it should be done, requiring teams to enforce strict coding standards through documentation and training.
AngularJS scope acts like a poor man's global variable, which goes against the principle of avoiding globals in JavaScript. While JSLint can't catch scope-related issues and developers are advised against using it, there's no built-in mechanism to prevent it, relying only on project rules and team discipline.
While directives are often presented as a magical solution to Angular problems, they hide too much complexity underneath. When directives break—especially when multiple directives are used on one element or when mixing custom and third-party directives—debugging becomes extremely difficult.
Yes, the distinction between these three concepts is unnecessarily complicated for what should be simple module helper functions. The confusion is so common that searching for 'Service vs Factory vs Provider' returns countless results, indicating this is a widespread pain point for developers.