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.

Introducing baked in modularity

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.

They’re all just classes

Everything in Angular is a class. With TypeScript as its typed superset, Angular is able to turn itself into its own programming ‘language’ while leveraging JavaScript, HTML and CSS as its tech stack.

Decorators are used to help the framework determine how to use the declared class.