26th Mar, 2021
4 min read
A lot of people tend to complain about how complicated Angular is when compared
to React or Vue. This is partly due to misconception, not to mention that React
is a library while Angular is a framework — making them very different tools
that essentially end up doing the same thing.
A lot of people tend to complain about how complicated Angular is when compared to React or Vue. This is partly due to misconception, not to mention that React is a library while Angular is a framework — making them very different tools that essentially end up doing the same thing. It’s the conceptual processes that determines your workflow and modes of thinking that are different.
Here’s a quick and simple rundown on how the main parts fits together in Angular, along with a few things I wished someone told me when I was in the beginning of my Angular 2+ journey back in 2016.
For those with an object oriented programming background, Angular is a lot friendlier to learn and mentally accept than React or Vue. In part, it is because it was designed to be highly modular and object oriented in approach from the get go.
If you’ve had the chance to work with the original Angular (aka Angular.js), version 1 is more library like in approach than the fully fleshed out framework that we know today. With Angular.js, you could just plop it into any existing application and it would work. Doesn’t that sound familiar?
But as applications grew, things became messy very quickly. Angular.js could be seen as ‘architectureless’ in that you could structure it in any way you wanted. There were style guides but it didn’t guarantee that one Angular.js project would look similar to another in structure and its ability to handle code growth.
Then in 2016, Angular 2 came out and paved the way for the framework that we all know now. Manipulating the DOM and connecting data was no longer the centerpiece as it was with Angular.js. Instead, modularity, re-usability and, OOP paradigms led the way.
Below is a conceptual diagram of what a simple Angular app could look like.
Decorators are used to help the framework determine how to use the declared class.
Decorators declared directly above a class tells Angular what to do with the rest of the code. It is just a function that extends and modifies the code that follows. So in the example above, @Component() declares the class HomeComponent as a component inside the app. In theory, you could rename it not to have the Component part for HomeComponent but the CLI generates this on purpose for convention purposes.
The above is an @Injectable() decorator that tells Angular that the ensuing class can be imported and used. This is also a reason why services are not registered inside @NgModule and have to be declared and imported in manually.
The main difference between @Component() and @Injectable() is that the first directly tells Angular to use the code with the referenced HTML and execute any binding markups to that particular template. @Injectable() simply extend the logic and processes of your code to your component.
This is also why services are often advocated as a way to separate out your application logic. In theory, your component shouldn’t be fetching data, validating inputs or log to console because that is a service’s job. The concept behind components is that it brings all the modular parts together like a lego board. The component itself is not supposed to participate in the processing or logical parts of your application.
The easiest way to think about components is that it is a space to connect data to HTML. Any transformation of data is to be left to a service. This will ensure true modularity in your Angular application.
Think of @ngModule as the index of everything that’s needed by your web app. When rendering, Angular doesn’t load everything but still need a reference to them when they are needed. This lazy loading methodology allows it to efficiently allocate memory spaces and reduce load times for your app.
It is also used in the build process of your application, where the things declared are what will be included in your final package.
You only need to reference classes and not HTML templates because component decorators have already sorted all that out for you. @ngModule only cares about the things that your app will consume. It gives a thing called compilation context to your Angular app and glues everything together through referencing.
Angular was designed to grow and therefore bakes in tried and true methodologies that have been tested in OOP based languages like Java. With React, it’s a free reign kind of experience. Angular, however, requires order and structure due to the lessons learned through the pitfalls of Angular.js.
There is still a lot more to uncover with Angular but I hope that the above diagram and explanations helped unravel one of the major parts that often appear seemingly complicated.
As local market trends begin to skew towards React, it’s easy to question the
future of demand for Angular. It’s a one or the other kind of game and makes you
wonder which once you should pick up, especially when you’re just entering the
Single-page application frameworks and libraries can be a blessing for
developers but a pain when it comes to properly implementing tracking and
If you’ve ever worked with Google Analytics, you would have encountered the
global site tag — or gtag.js. Google tells you to pass this code as
The idea of modularity gets thrown around a lot, especially in the space of
clean and structured code. It’s one of those ideas that’s just supposed to
implement itself if you repeat it enough in a sentence.
When it comes to Angular, achieving modularity is more than just
Why things no longer automatically flow both ways