4 Reasons to Use Angular for Your Next Web App

Explore why community, momentum, stability and framework might make Angular the right place for you. But, ultimately, the choice is yours!

Here they are—the four reasons to consider Angular for building your next web application:

• Community
• Momentum
• Stability
• Framework

Those might sounds droll, but I believe them to be the honest truth. Angular has a phenomenal community, with thought leaders that not only innovate but lend a helping hand to those just getting started. The framework itself, the codebase, has a lot of momentum. Many innovations and changes have and will happen, all centered around a better developer experience, an easier onboarding and a more performant byproduct.

As far as stability, I have never seen a team as conscious of breaking changes and being evergreen as the current crew manning the Angular ship right now. With every decision comes hours and hours of deliberation, brainstorming and checking with community members that this is the right next move for the framework going forward. They aren’t afraid to innovate, but they don’t do it at reckless pace either.

Lastly, framework. Angular is a framework, not a library. If you choose to walk into the world of this framework, you will find best practices and architectural decisions pre-made. How should you manage state? The path has been paved, repaved and paved again. There are clear formulas and constructs to use—as, with any true framework, many of the early deliberations are removed, freeing you to simply create.

Community

As I mentioned in the opener, Angular’s community is truly fantastic. I believe the reason for this is two-sided. The Angular team has always been eager to have relationship with its outside user base. They have a great advocate program for training and support thought leaders, they make an effort to be at conferences and meetups throughout the year to answer burning questions and educate their community, and they also love what they do. I believe the Angular team’s vibe has strongly influenced the vibe of the external community of developers.

I also believe, that certain “types” of people gravitate toward certain types of code. Angularites are full of people from all different backgrounds, but there does seem to be a common chord being struck in their personalities. Some are cool, some are nerdy, all are passionate creators, but the one true note I see is the vibe of “you can hang with us, you can chill here.” Angular isn’t going anywhere. We have this cushy sense of comfort and stability for the framework and for the community that is very soothing and, I daresay, catching—so watch out.

Momentum

It started back with Angular 1.0 (now called AngularJS). Decisions were deliberated, a path was forged and a framework was born. Then, for 2.0, many new decisions were made, new docs were created, and the distinction was made between Angular (v2.0+) and AngularJS (^v1.0).

Now, with Version 17, we are looking at more innovations and more changes (outside the normal growth) but in a backward-compatible and migratable way.

Looking back, it is interesting to see the things that held us back from being the framework the team would have us become, shortly. There were technology considerations and internal influences that led to the shape of the framework. And now that the landscape has changed and web tech has advanced, I’m proud of the team, my Angular team, that has the gumption to look at a very hard task (both code wise and community advocacy wise) and tackle it with all due vigor—all for the betterment of the framework and its community, always.

At this point, I probably sound a bit dramatic. As you can tell, if you didn’t already know me, I am a die-hard Angular fan. But I have found such belonging here and such passion here that it is hard not to come off strongly.

The momentum that the framework now has—after the rendering engine paved the way for innovations such as standalone, signals, control flow and even the new build system—is palpable. Stepping into Angular right now, you not only feel there are so many cool tools in your Angular tool belt for app-building, but you get this sense of motion and hear the promise of features to come.

Stability

Angular is a framework written by Google for Google. And for the community. Google has over three THOUSAND internal applications. They all use Angular. Angular is dogfooded by its own creators and by everyone in the company as well as the vast worldwide community. This framework, simply by who it serves, has to be stable.

What does stability give you, personally, as a developer? Lots of things. A stable framework means thorough docs and demos to learn all of the pieces from. A stable framework means if the docs don’t cover it, you can guarantee the community of passionate users will. A stable framework means you won’t have the rug pulled out from under you.

Interested in a feature that is marked RC? Awesome! I’d recommend using it as soon as you are able. Features that make it to RC in Angular are in their final stage of community testing, they are stable, they won’t be “taken away.” At worst, their API might be a little more robust in the final release.

I know what I can expect from Angular and Angular’s future. I know what I can expect from the Angular team. I know what I can expect from the community. I relish the stability of it all. Passion is nice when you are young, but the older I get, the more comfort I find in the known. Angular is stable.

Framework

Unlike a very popular alternative (React), Angular is a full-fledged framework. (Say that five times fast. 😏) This means you have solutions that are fully baked and outlined, docs that are thorough, and a healthy community chock full of tutorials, videos, blogs, etc. I personally like having decisions like “who is my router” or “how do I manage state” pretty much handled and wrapped up in a bow for me. It does free your mind up from the crufty bits to the actual building, which should be what we do as developers.

Some people enjoy the “roll your own” approach and freedom that comes with a library. At least, they enjoy it until it comes time to maintain the beast long-term. I feel there are too many heavy important decisions to be made at the beginning of an application that require a true dev architect and semi-warlock to look into the future and see which direction we should be going. Not every team has a warlock and many teams are paying for that right now, in the long game. With Angular, you don’t need magicians on your team, which is nice.

Choose Angular … Or Don’t

I remember sitting in the front row at one of my first ng-confs (along with about 1,700 other souls). I was watching the brilliant Brad Green present on the upcoming plans for the framework. During the Q&A, someone from the audience posed the question, “Why should I choose Angular over React?” I was shocked and laughed out loud at Brad’s response. Brad said:

“You shouldn’t! If you want to use React, use React. I won’t make a penny more or less either way.”

I loved Brad for that answer and I love that this spirit has persisted on the Angular team. Features aren’t created because they will be popular. They are created because they will make the framework better, they will make it easier to learn or use, they will make it more performant. Not because it will make money or sell.

I suppose that is the beauty having such a tech beast create, back and use your framework. If the community disappeared, Angular would remain and still be utilized by hundreds of devs on thousands of apps at Google. They needed a framework that answered these problems and so they created and maintain it. The fickleness of developers in the community has no sway on the direction or existence of Angular, and that is a beautiful thing, a stable thing.

So, for building your new web app in 2024, use Angular … or don’t. This community will still be here, stable and strong as ever. We welcome you if you want to hang but we also wish you well if you don’t. May your code transpile and your tests all pass, my friends!