Hackernoon logoEdgy corners of AngularJS by@bhatt.shashwat

Edgy corners of AngularJS

Shashwat Bhatt Hacker Noon profile picture

@bhatt.shashwatShashwat Bhatt

Project Manager

of 1.x versions precisely, I am not here to sing the praises of BackboneJs or KnockoutJs neither I want to draw comparisons between them but after working about two years with it there have been times when I thought I wish someone should have told me this edgy corners beforehand.

The famous AngularJs learning curve

Me and many of my JavaScript developer friends have experienced this. There have been times when we have thought we almost knew how it worked and the day after that Bam! something new poped up and we went WTF! we never thought about it.

1. Two-way data-binding

It means :

  1. When properties in the model get updated, so does the UI.
  2. When UI elements get updated, the changes get propagated back to the model.

What many developers fail to realize is that just because it looks cool and gives a wow! effect to you application does not mean you need two way data binding, And it comes at a very high cost because this has been implemented via dirty checking and digest cycle.

dirty checking:

AngularJs on every browser event runs a digest cycle which literally evaluates every expression in your application (like really!) and if it finds that the value of that expression has changed it updates the values of expressions. All of this happens in the blink of an eye so you don’t really see browser lag but when the expression on the current DOM structure reaches 2000 you will be able to see the problem.


Few months ago Google has released AngualrJs 1.5.x which has one way data bindings features which can help minimize problem

Digest Cycle:

We have already discussed the problems with digest cycle, but one of the biggest problems that I have faced is that when something changes outside the scope of AngualrJs we have to manually call a low level API $scope.$apply() and meanwhile, if Anguar has automatically started the digest cycle “already in progress”- error will popup and it will screw you!


Yet to be found.

2. Dependency Injection

In Angular dependencies are injected by the name of an argument.

function MyController($scope, $window) { // … }

Here Angular calls .toString(), gets the names of the arguments and then looking for them in the list with all existing dependencies.

Don’t see the problems?

  1. Try minifying your code it will stop working.
  2. Even if by chance you miss a single dependency, AngularJs will not run and you will see a blank page in front of your screen.
  3. Forget lazy loading, you have to load all the dependencies prior to angular.bootstrap is called.


You can use this syntax…

someModule.controller(‘MyController’, [‘$scope’, function($scope) { }]);

or this

MyController.$inject = [‘$scope’, ‘$document’];

or use a plugin like ng-annotate.

3. Debugging

Debugging in JavaScript is sometimes a headache but AngularJs makes it more difficult i.e,

<div ng-repeat=”user in users”> {{ user }} </div>

if there is any error in this binding rather than showing it in console the elements won’t be added in DOM because Errors in bindings don’t fire at all because errors that occurred in JavaScript are caught by the internal angular interceptor, and interpreted by browser as caught errors!huh!


Yet to be found.

4. Directives and all the unnecessary complexity


Everybody is crazy about them, people just worship them for some reasons! But I’m pragmatic, here is complete syntax of the directive declaration. To understand this syntax and why you need it, you really have to spend a lot of time. Instead of writing WHAT to do, you think about HOW to do it. The sad thing is this- complexity is useless. There is no logical reason to separate logic for 3 methods (compile, link, controller), all these can be easily implemented in a single method. Also take into account that some functions get scope, some not, some execute only once, some every time with $digest cycle, and every directive also have the priority. Even in order to integrate some code in the angular world, you need to wrap it in a directive. Now don’t get me wrong, once you get hold of them they are the most awesome things ever, but frameworks are supposed to make developers life easy not complicate it.


Practice and study them hard and expect it will pay off.

Inability of server side rendering:

If you try to use server side rendering, for example to speed up page rendering, or for SEO (or both), then you will be disappointed!


You will need to use prerender.io (the service, that parses your partials and gives you HTML files that should be given to crawlers). But again ahhh — it’s a hack, and not a solution of the problem!

Too many ways to do the same thing:

Angular provides lots of ways to do the same thing, like different kinds of services (factories, services, providers). There’s also several ways to use a directive (element, attribute, comment, same scope, no scope, isolated scope), and several ways to use a controller.

All of these adds into the complexity, learning curve for new developers, lack of conventions, and lack of best practices to enforce. This is bad for the ecosystem around angular, both user-developers and library-developers.

5. Router:

AngularJs uses ng-router for routing and it is fairly simple to use as you might know, but it lacks basic features (nested views and states), so, for that you need to use Angular-ui router which is perfect and I have used it for many projects but to get started in it is very difficult and sometimes you need to use other libraries to work with Angular ui router.

So let us get this straight, you are using AngularJs to solve your problems and you are now using ui router to solve routing problems and other 3rd (or 4th) party libraries to work with Angular ui router(pheww)..

Now, I know the story about how AngularJs was not intended to be what it is today and it has grown organically but these are some rough edges which should have been solved long ago.

Now don’t get me wrong, I love AngularJs and I still recommend it to the people whose application’s architecture needs it. I have started making small applications in Angular 2.0 and most of these problems are not there, so if you are new to Angular or have not started development yet, you can use 1.5.x version or version 2.0(after stable release obviously!)

Thanks for reading. Feedbacks and comments are always appreciated.




Join Hacker Noon

Create your free account to unlock your custom reading experience.