Angular’s not that bad — not as bad as React developers make it out to be. The thing is, we’re usually biased towards what we know. For outsiders looking in, Angular can seem convoluted, massive, and somewhat complicated. But what many don’t realize is that it’s all the same JavaScript under the hood. The only major difference is how the JavaScript is structured.

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.

It’s all just JavaScript

At the base of everything web and front end related is JavaScript. It doesn’t matter if you use React, Angular, Vue, jQuery, Ajax, or node, it’s all a form of JavaScript.

The issue that the industry faces is that many developers, new and transitioning, often pick up JavaScript but never get around learning it properly. This is partly because JavaScript is easy to pick up. You can just create a bit of code and most of the time, it’ll just work. There’s no complicated set up required, no structural implementation, or exported compilation. It’s a scripting language by design, meaning that it’s compiled and interpreted at runtime.

This often gives many developers a false sense of mastery, leading them to jump right into libraries and frameworks without background knowledge of the language itself. Having a computer science degree won’t save you from JavaScript. Only learning JavaScript will save you from JavaScript.

In truth, JavaScript isn’t that bad. It was designed to be easy, and that was part of the appeal intended by NetScape — a name that can evoke a million reasons why the 90s ended up with so many random snowflakes and kitsch page effects. With the help of Apple’s ban on Flash applications, JavaScript accelerated its pace to take over the web.

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.

This means that Angular favors decomposed code design that are abstracted out into individual functional or logical components. These components are well-defined with clear methods, events, and properties. It leverages JavaScript’s object-oriented ideologies and embraces the class declarations in the form of TypeScript.

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

The major price of Angular is mostly the learning curve required, especially if you’re not a native JavaScript developer, or have a deep understanding of vanilla JavaScript.

Because that’s what Angular boils down to — vanilla JavaScript — which is JavaScript without the bells and whistles, the architectural and pattern enforcements. If you understand how vanilla JavaScript works, mixed with a dash of creational and structural based patterns, picking up Angular is much easier and faster to comprehend. TypeScript just makes it visually easier to work with and implement object-oriented based ideologies that aren’t natively available yet in JavaScript.

Whatever the case, you can’t escape vanilla JavaScript. It’ll always be there, no matter where you go in the world of front end web development. So if you think Angular sucks, you should take a step back and take a look at vanilla JavaScript first, only then can you truly appreciate the implementations made by the framework and its intentions towards sustainable scalability, code controls, and coordination.

Comments

0 comments