Why we chose the new Angular

In my article, I want to share with you the experience of using the new Angular as the basis for our enterprise applications. Speeches that the new Angular is better than React, Vue or some other popular library now will not work in the article, although, of course, I will compare it with competitors. All solutions have their pros and cons, and what is well suited for one project can make a living hell in another. So, before explaining how the new Angular has hooked us, I’ll tell you a little about what we are already using in development.

Our main project has a long way of development and is built on already outdated technologies - Marionette + Backbone + Coffescript. A couple of years ago, we realized that developing the project in such a stack became quite difficult, and began to explore alternatives in the frontend ecosystem and think about how we can migrate our “beast” there.

Starting work on a project, we chose the currently popular stack React + Redux + [Reselect, Redux-Saga, Redux-form, etc]. This was our first attempt to select a new stack and, unfortunately, unsuccessful - it seemed to us not so convenient as Marionette many years ago. As a result of research about six months ago, our choice fell on the new Angular and we are happy with it. So far, the new Angular is not used on the main project of the company, but in the future we see no obstacles to its transfer to this solution (well, except that the huge code base on Coffeescript stops us). So let's see what we found in the new Angular and how we liked it.

Items will be presented in no particular order, but not in order of importance. We begin, of course, with those things that we consider the advantages of the solution, and in the end we will talk about the disadvantages.

pros

Angular is a framework

This is one of the most important advantages for us. When five years ago I started a project in a company, I thought it would be easy to build a cool and holistic product. How naive I was! :) The more people connected to the project, the more time I spent on bringing the whole “zoo” of solutions to the overall style and architecture. In part, this was due to the freedom that Marionette gave us, because it was only a set of primitives, which did not limit the developer.

All people are different and everyone will build the code of their own piece of product as he likes. As I just did not struggle with this problem - I entered the coding style, reviewed the code, made a description of the architecture, but I still occasionally came up with a non-standard solution from one of my colleagues, and I had to spend a lot of effort to return the project to the same development and architecture.

Then there was the development time for React and, it would seem, Redux and Flux came to my rescue. Yes, it allowed not to worry any more that the change of these models would be scattered around the code, but one of the problems still remained. I had to keep track of all the libraries that were being dragged into the product. Our stack just dazzled with its diversity and approaches.

Then we switched to Angular. Despite all its flexibility, it’s still a rather restrictive developer framework. And since it contains quite a lot of possibilities, the introduction of a new library into the project became for us a rather rare event that was easier to control. Having the same coding standard provided by the Angular team allowed me to finally breathe out and relax, and devote more time to development.

Of course, in Angular, you can still create chaos, but this is much more difficult to do, since the incorrectly constructed code immediately pops up either when evaluating performance or when trying to reuse it. I would be glad to have a more rigid framework, but, I am afraid, then we would lose the possibility of its expansion, but I would not want it. It seems to me that in Angular we found a middle ground - this is not allowing all of Marionette, but also not hard Extjs.

Having a cli system

This, of course, is far from a killer feature of the angular, and React also has its cli (react-starter-kit), but nevertheless, it is much easier to start exploring a new solution using the console client, rather than spending hours choosing boilerplate and search for the reasons why something is not working. In addition, the console client has a huge plus in the fact that it immediately generates a minimal application template, allows you to easily run code in development mode or in production, and run tests.

All this, of course, reduces the entry threshold and allows you to immediately start writing business code, without thinking (up to a certain point) about the location of the files or about writing the application skeleton. You also need to pay tribute to the guys from Angular - their console client is built on top of the emberjs client. Once upon a time I came across ember and was pleasantly surprised by the convenience of their console client, although this was the only advantage of ember that I noted at that time.

Typescript

When Typescript only appeared, we did not understand its purpose and believed that type checking is all “from the evil one” and we don’t have so many defects due to incorrect data transfer. Over time, we changed our minds and even tried to introduce the flow package into the finished project, but after a week of torment we gave up and decided that we could live without it.

Then we paid attention to Angular, which is completely written in Typescript, and thought, why not try working with it again. The first thing we appreciated after switching to Typescript is the ability to easily use es6 without unnecessary messing around with the settings of babel and other transpilers (and the confidence that the next update will not break your code build). You simply write the code, and the compiler easily converts them to es5.

But most of all we were pleased that writing code in the IDE has become much more convenient and pleasant - autocompletion works correctly, you can view the documentation of the method without leaving the code context, the code has become self-documented. We no longer needed to describe in the comments what kind of object we pass to the method, this provided Typescript for us.

A little later, we appreciated the beauty of interfaces and decorators. Yes, of course, you can write to Typescript using React, so this is not a unique plus for Angular, but when the framework itself is written in Typescript it gives you seamless integration of your code.

Component approach

Almost all current solutions use the component approach paradigm and Angular is not the first to offer such a solution. But if you compare the Angular approach with the approaches of other solutions, there are a number of differences:

• You can not only create new tags for html markup, but also change existing ones. Not always when using React, we managed to make a clean markup without unnecessary html-elements in the hierarchy, and this terribly annoyed our layout designer. In Angular, you can change the behavior of an existing html tag through an attribute, and this makes our markup cleaner and more pleasant.

  
  

• You can put the layout in a separate file. In our company, JS-developers do not like to type out html, so we have a layout designer. When he was doing the layout of the React-code without knowledge of JS and es6, for him it was like walking in a minefield. I know that in React there is an opportunity to put out markup, but when your code is generated by a set of JS functions, it is not so simple. It turned out that it is easier to explain to the layout designer what things he shouldn’t pay attention to (talking about directives, of course) than to teach him JS. Using Pipe allowed us to hide from the layout designer all the complex magic of data processing, leaving only a small interspersing of directives.

  
  

• You can customize the behavior of the component by changing the settings for the Change Detector or working with the CSS classes. Moreover, when inheriting from the base components, all your settings will be saved. Thus, it is possible to enable the change detector operation in the comparison mode of immmutable objects by one parameter, and when inheriting from such a basic component, to avoid unnecessary change detector detector cycles. Of course, this requires the developer to understand what he does when inherited from the base class. The encapsulation of styles allowed us to avoid suffering with the choice of the name for the next class selected inside one of many components.

  
  
• You can specify which parameters the component can receive at the input and which events can emanate from it. After that, when you try to pass an extra parameter to the input of a component, the compiler will let you know that the component knows nothing about such a parameter. This helps to avoid mistakes when using other people's components. Of course, there are PropTypes in React, which also allow you to control what goes into the input of your component, so Angular is not unique here.

Rxjs

Angular is built on top of the RxJS library and it was strange not to use it. But when we first encountered this library, we were horrified. It took us several days to figure out how to properly write our data processing chain. The result is a code that can be read only by someone who has ever tried to write something on this library. It scared us so much that we even thought about abandoning the use of RxJS.

Some time passed, we re-read the documentation several times, tried the library in action and got used to it. The RxJS library allows me to do very cool things with data processing and almost always my code works as I had intended. True, even now, after six months, I realize that I do not fully know the full power of this library. But on the other hand, I understand that I would hardly refuse to use it.

Of course, RxJs can be embedded in React, but again, when your framework uses the same as you, you can easily associate your code with the framework, for example, using the Angular HTTP module to work with backend.

Dependency Injection

We must start with the fact that Angular is used almost everywhere by Dependency Injection, which means that it gives you the opportunity to change the framework's behavior within very large boundaries: you can wedge in certain work processes, for example, construct routes at the start of the product, you can completely replace some parts of the product with your own.

In addition, Angular's DI is so flexible that it allows many well-known patterns to be implemented on it, such as Singleton, Factory, Facade, etc. We use DI everywhere, from the interaction of components to the creation of services for displaying modal windows or notifications to the user. And of course, all the work with backend is built through services and DI.

I am not a supporter of the redux approach, because I have a negative experience with it - (in one of the projects I was tired of a huge amount of sample code, often large redux saga handlers and slowing reselect getters). We may have used it incorrectly, but it seems to me that this was not the case. We built this entire stack into the finished project with its interfaces, and did not build a new one, sharpening the work with the backend for convenient installation of everything into the state and side-effect handlers.

But back to Angular. If you do not need a redux approach, but you want to have a so-called “single state of true”, then you can use services, RxJS components and Uniderectial data flow supported in Angular. The code will be much more compact and will be no worse than the redux approach. Over time, you can transform it into a redux approach, almost without changing the code. How this architecture will look at the end, you can see here .

Modules

For the first time I met with modules in Marionettejs and it was incredibly convenient. I split the module into many files - controllers separately, views separately, etc. And after Marionette gathered for me all together.

Being engaged in the development of a project on React, I often remembered about the modules, but I don’t suggest anything like that from the React box, but I didn’t have time to look for or implement something like that. Angular, on the contrary, gives you the concept of a module from the very beginning. And they make it easy to work with the codebase. You simply assemble all the pieces of your business component into a module, and to use it by another developer, you simply add your module to the code.

Since the modules have their own namespace for the components, you can not worry about the fact that your "insides" will be available to someone in the external code. This is a great layer of abstraction from the rest of the code. And of course, you have the opportunity to export the necessary components to the outside, so that other developers can use them.

In addition, modules are a great tool for documenting code. Of course, there are features of using modules and you need to know about them. The first feature is that the services defined in the module are available to the entire application, and you need to be careful with the naming of these services. Angular proposes a solution in the form of using the Symbol type analog from the new JS standard to avoid collisions.

The second feature is hidden in lazy load-modules and lies in the fact that services loaded from such modules are only available inside the module. This is a rather unpleasant feature that made us look for a workaround, since our product is built on a plug-in system and we need unhindered access to services. We have eliminated this feature due to early preloading of services at the start of the application.

Framework development and support

Angular, in contrast to React, is developed by only one matener, Google, and for us this is important. From our experience with React, whose development of the stack, in essence, is in the community, we came across a couple of times that the selected libraries stopped supporting or had a very low defect correction rate, and this hampered our development.

A couple of times we had to change one library to another, and many times we had to fork the library and make our own changes. Yes, we are not immune from this and with Angular, but here we have much less third-party libraries due to the fact that the framework contains much in itself. As for the defects in Angular itself, with urgent need, you can use paid support from the Angular team, which will help solve the problem or find another solution. But, of course, this will have to spend a little budget.

This is not all the advantages that Angular has, but only those that seemed important to us. In addition, Angular has the ability to translate code into WebWorkers, which will make it multi-threaded, Server Side Rendering and much more. Now we don’t need these capabilities, but it’s nice that if we need them, we can use them at any time without changing our code.

Minuses

Like any other solution, Angular is far from an ideal product and, of course, contains cons.

Pretty mediocre documentation

The documentation is there, but its quality leaves much to be desired. Often, opening the documentation, you can see just the name of the class methods, without any description of what they do and how. Even if the description will be present, it is not always possible without a living example to figure out how to use this or that method.

Who tried to create components in Angular dynamically, they will understand me. Some things are simply missing from the documentation, and you have to go into the code to figure out how to achieve the goal. But I think, over time, this problem will go away, and the guys will finish the documentation.

Large amount of result code

If you use Angular out of the box, then at the exit we get a hefty modules, from which comes the longing and sadness. But if you dig a little bit in the documentation, you can find a number of solutions that will significantly reduce the size of the output code. And here there are several approaches:

• Exclude those modules that are not used. For example, if you don’t use the animation that Angular offers, or the forms, you don’t need to carry these packages with you. You can also use tree-shaking when building a project, which will exclude unused parts from the code. For example, it will greatly reduce the size of RxJS, which you include in the production code.

  
  

• Use AOT compilation, which will exclude the runtime compiler from your code, and it weighs a lot. True, this is possible only if you do not generate components dynamically, as we do. But even in this case, the compiler can be put into a separate module and loaded separately.

  
  
• Use Lazy loading modules. Angular router can work with lazy loading modules out of the box and even allows you to choose a module loading strategy or write your own. By default, modules are loaded only when they are first accessed, but you can specify module loading in the background, which will speed up the transition to sections loaded by modules.

For us, this minus is not particularly critical, since our application is released every six months, there is no huge load on it, and the browser cache will save us. And we do not assume that someone will use it from mobile devices, for this purpose it is better to make a separate native application.

Difficult entry threshold

Angular is a very complex framework. On the one hand, using cli, you can easily start writing code on it, but, on the other hand, without examining the documentation, for example, how change detector works, you can write very non-optimal code or even non-functional at all.

We also did not avoid this minus and killed quite a lot of time trying to understand why the service from the lazy load-module is not visible in another module. In addition to the very complexity of Angular, the RxJs library took us a lot of time, which is not so easy to understand, but worth it.

Conclusion

Based on the above, we came to the conclusion that Angular has become a truly corporate framework in which you can not be afraid to build large applications. This was mainly due to the comprehension of experience with the first version of Angular, the chain of correctly made decisions, for example, the choice of RxJs and Typescript, as well as the integrity of the decision made.

React for us is a collection of good ideas, but due to the lack of many functions out of the box, often each of them sculpts his own “monster” from the opportunities provided by the community. As a result, the time of entry of a new developer into a complex project is much greater than that of Angular, and often problems arise even among neighboring teams. But, I repeat, this is purely our opinion, derived from our experience and the projects created. Choosing Angular, we care about the speed of our development and how quickly our developers can make changes to the code, moving the product forward.