Angular itself doesn’t really suck. If you think it does, most of it is probably in your head. There is friction against the framework because it looks and works somewhat differently from what you’re used to. Or perhaps it’s simply not doing what you want it to do because there’s a gap in your knowledge.
Yes, I’m an Angular developer. But I’m not advocating it because it’s my native framework of choice. If you’re looking for a React bashing kind of piece with Angular placed on a pedestal, this isn’t it. This is a discussion piece, something that sits above code nuances and x is better than y kind of talk. It’s a meta-perspective on code, the functionalities, and where Angular sits on the spectrum of our ability to use it as a tool.
But as projects grew in size and the number of requirements increased to match the growing complexities of the online world, frameworks and libraries that we know and love so dearly today became a solution to the growing code management problems.
Angular was one of them. With the help of Google’s support and backing, it morphed and transformed into the framework that we all sort of know today.
Everything has a place and purpose
Angular is a framework — which is vastly different from libraries like React. People often compare the Angular and React. But the issue is that you can’t fairly do so since they have different reasons for existing and are structurally different.
A framework is a collection of libraries, coordinated through an interface that makes it easier to tap into the features and functionalities that the library offers. This process of ‘tapping’ is uniformed through the framework’s methodology of communication and how it structures itself. In the case of Angular, it’s architecturally component-based.
React is a front end interface library that manages the ‘painting’ of information on a screen. There is no enforced architecture or design pattern, other than JSX syntax. This decision is mostly left to the developer.
As a result, Angular is often viewed as being architecturally ‘rigid’. While you can just plop a piece of React code almost anywhere, Angular, in comparison, requires a bit of setting up. But with rigidity comes a certain strength, especially as the application grows and uniformity is required by the team to keep moving forward in a structured manner. It gives the project predictability and an Angular developer has the ability to move between projects in a seamless manner.
Micro-front ends and inverse architectures
Angular is often viewed as the monolith project that doesn’t work well for transitional apps. However, this is mostly due to the common starter tutorials dealing with creating apps from scratch. There is a gap in discussions on micro-frontends with Angular.
What’s a micro-frontend?
It’s when an app is made up of a myriad of multiple technologies, frameworks and libraries. It happens quite a bit, especially in legacy systems trying to upgrade but don’t quite have the manpower or budget to recreate an entire system from scratch. There is an underlying framework that keeps everything stitched together. Sometimes it’s Angular. Sometimes it’s something else.
When it’s something else, Angular has the power to sit in a compact and contained manner through a thing called Angular Elements. Its other names are ‘Web Components’ or custom elements. It’s a methodology that allows you to create framework agnostic and packaged pieces of code that can sit outside the traditional Angular structure.
The final result can plop right into a page and remain separate from the rest of the application if required. You can almost think of it as a mini Angular application sitting inside another application. It might be React. It might be Vue. For all we know, it might even be a Java Spring incarnation or PHP based app.
Why does this matter?
It means that if Angular is the route you’re aiming to walk down for your transitional projects, it’s a matter of unpackaging the pieces and putting them together again. The modularity of its design means that it can remain isolated and separated from the rest of the application, or integrated into the fully transitioned Angular app. This can save your team time and the need to refactor architectural designs.
The price of Angular