Why I hate and love Angular at the same time

I hate and adore Angular at the same time. Two-way binding, MVWhatever architecture, the speed of small applications development – are like a blessing after problems with jQuery. But still Angular has it’s own problems and problems related to all new frameworks.

It’s much harder to start working with Angular rather than with HTML and CSS. If someone puts you on a project with Angular you can get along with the project quite fast and start to think that Angular is a simple thing. But one day you can face the situation when you have to create Angular web-application from scratch and then you’ll know that all knowledge that you have about $scope, working with $services and creating directives are just one part of Angular. You’ll realize that in order to create a web-application from scratch you need to know about Routing, types of Dependency Injections, modules-splitting strategies, global backend errors processing and much more points about architecture of Angular application.

The other treacherous minus for junior developers who have chosen Angular as a first framework to learn is that Angular doesn’t teach you how to work with DOM and javascript events. Angular has dozens of internal directives and thousands of open source plugins that solve all problems connected with DOM and events, so a developer who works with small applications almost never has to think about that. That’s why instead of jQuery-programmers we now have Angular-programmers.

One more big reason why many people prefer React or Angular 2 to Angular 1 is that Angular 1 has big performance issues. If you have chosen Angular for a big project with lots of pages, forms and grids with a large amount of data on a page – be prepared to use one-time binding everywhere, rewrite Angular libraries to native script or jQuery, work with DOM Bypassing Angular, be ready to kill watchers and delete scopes. The problem is that Angular adds watchers for every item he sees and triggers each watcher at least two times for every call because of the $digest cycle features. That’s why your Angular application will start forcing issues with performance not bit by bit but suddenly. To render 20 rows of table data Angular needs a split second. Rendering of 1000 rows with Angular is too slow to show it to product owner.

The biggest disadvantage of Angular as well as many other frameworks I have met is dozens of unobvious unwritten rules of how to work with Angular in a proper way: should we split application into modules or not, what is the proper way of naming angular-based modules in Controllers, a fact that working with DOM from Controller is bad, using controllerAs strategy and over $scope, etc. And the more confusing thing is when on some projects some rules are applied, some are deliberately ignored and some of them no one had even thought about.

Debug is always a distress of all modern Javascript frameworks and Angular is not an exception. Every time I have internal Angular error that I haven’t noticed at the very beginning I know that I’m in trouble. To find a cause will be a big issue because browser console link to Angular official website gives only basic info of the nature of an error. You can’t get the exact place of the error or at least a filename with it. The worst of all errors are those with Dependency Injection and Routing.

If you want to fix the error with Dependency Injection, it’s better to use the following strategy for unwinding the coil of dependencies:

1. Remove or comment out connections of all modules in the main file app.js
2. Remove or comment out connections of all Angular js Controllers and Services
3. Check that the application starts without any errors running only index.html
4. Return to app.js connection of the first module
5. Uncomment the corresponding js file in index.html
6. Check that the module is loaded and the application is running
7. Repeat steps 4 and 5 until we find the module upon the return of which the application stops working
8. When you find the problem module, you need to find out the cause of the error: check the module name, check the module file's connection to index.html and correctness of the path specified to it, check the Dependency Injection inside the module for errors in the names, if you use array notation you’d better check the number of dependencies connected outside the dependency array and inside it

It could take up to several hours to find and fix such issue if you know where and what to look for.

Routing problems are solved a little easier. If you go to some page of Angular application and you do not see the page you need or the opened page is empty at all, then often the problem is that you forget to register routing, or you have made an error in setting routing URLs, or maybe you have a syntax error in the file name. Such problems can be solved in the following way:

1. Find the page for which routing works correctly, let's say it's login page
2. Find the routing settings for the login page and create a copy of them with the only difference in the URL that points to your problem module, for example, on settings module
3. Check that URL of ../login and ../settings points to the same place in the login module
4. Create an absolute copy of the login module, then change the name of .js files, then the module, and then the code inside the module
5. Catch errors in step 4 and fix them

I hope this post will help those who are just starting to get along with Angular to do it faster and will help to continue working with Angular and understand all its details and features, to love it’s pros and to forgive cons.