DEV Community

Cover image for My Completely Biased Reasons for Choosing Angular

My Completely Biased Reasons for Choosing Angular

John Woodruff
Senior Software Engineer at GoReact, previously Domo. Co-author of Your First Year in Code. Working on something new.
Updated on ・8 min read

I wanted the title to be painfully obvious. Just in case that didn't make it obvious enough, let me be even more clear. This is my completely biased opinion. You possibly vehemently disagree with me on this, and that's okay. This is not a post to try to claim Angular is better than React or Vue or Svelt or whatever other framework you're in love with. It's literally a post talking about why I, John Woodruff, choose to use Angular in personal projects small and large. Honestly, I'm not even trying to convince you to use Angular. In fact, my honest advice for picking a framework for a project is to pick the one you know the best, so you can be as productive as possible. So let's get all that out of the way up front, and dive into my heavily biased reasons for choosing Angular for personal projects. Keep in mind, when I make a statement it's an entirely opinion-based statement, so take it with a grain of salt.

Opinionated Framework

Let's talk about one of the hottest topics up front. Angular is an opinionated framework. If you're not sure what that means, basically it's that the Angular framework defines how you should build applications, and they provide all of the essential tools you need to be able to build your applications. They provide solutions for routing, data fetching, internal data flow, and more, all bundled in the framework itself. Contrast this with something less opinionated like React which specifically does not define how you should build applications, it's simply a library to build components. You can then pick and choose any number of libraries for all the pieces you need to build your application, specifically the same things I mentioned above.

So why is that a hot topic? Well, opinionated or less-opinionated frameworks or libraries elicit all sorts of responses from the developers who use them. Many developers are very against opinionated frameworks, where many other developers love opinionated frameworks. So naturally many of the arguments both in favor of and against Angular are based on the fact that it's a highly opinionated framework. They have rigid structure for how Angular apps should be built, and many tools included out of the box.

Well here we come to my first of several biased opinions. I love Angular because it's an opinionated framework. I love that I don't have to pick and choose from a million libraries to put together a complex app. 95% of what I need is already included in the Angular framework. I also don't need to decide "how" I want to build my applications, because Angular has a detailed style guide for building applications, and I'm able to focus entirely on the actual implementation of my application.

This is also why I love Angular for large complex apps within work environments. When working on teams there is often friction due to different teams or team members doing things differently. With Angular you eliminate a lot of that, because there are defined ways of doing things, and so it's far easier to scale across an organization. Having worked on large complex applications in work environments using both Angular and React, it's been infinitely easier to work within Angular applications due to the lack of a lot of the friction we had with the large React applications. It came down to Angular being opinionated, so there was far less mental overhead.

Angular CLI

Image of the terminal with an Angular CLI process running

Ah the Angular CLI. This goes right along with the previous point of Angular being opinionated. The Angular CLI is the best way to build Angular applications due to it tightly following the Angular style guide. It generates a fully scaffolded Angular project for you, and has numerous generator commands for adding new components, services, modules, etc., has automated testing all set up for you out of the box, and more.

It also completely controls your build process, which means they fully manage the building and optimizing of your application. So all of your production builds make use of optimizations such as ahead-of-time compilation, source code minification, tree shaking, style auto-prefixing, and more. This is all stuff that you would have to figure out and do yourself using a build tool and numerous libraries and plugins. Instead of wasting time on all that, I can enjoy knowing that the Angular CLI is generating the best possible production build for me and I can focus on building awesome features.

Version Updates

One of the best features of Angular CLI, if not the best feature, is the ng update command. Ever since Angular 6 was released, the Angular CLI has included this command. It takes basically all the work out of doing version upgrades, and the Angular team did an absolutely phenomenal job of making this command work exceptionally well. They even have a super helpful Update Guide which gives detailed instructions, but almost all of them say that the changes should be automated by the ng update command. Normally when you have a major version update, you would have to manually go through your app updating dependencies, delving into changelogs, changing code in your app in numerous places to get rid of deprecated or removed features, and then painstakingly testing to make sure you haven't broken anything. This command, however, automates essentially all of that, including running code migrations that automatically migrate you to the latest recommended syntax. There have only been a handful of times where the changes required manual intervention in the code, and usually they were exceptionally quick to resolve. All the rest is fully automated by Angular CLI.

Ever since this command was released, I have spent approximately 5-10 minutes updating to the latest each time a new major version is released. Contrast this with major version upgrades that can sometimes take hours or even days to update your large complex applications to the latest versions. It even allows library authors to define their own schematics to automatically update their libraries, and that's awesome for users of the framework to not have to worry about manually keeping those up to date when they can just automate it. This has saved me countless hours every single time a major version is released, and I am completely spoiled when using other frameworks that don't provide this incredible functionality. (that's actually another upside to opinionated frameworks, it allows features like this that are otherwise unrealistic with unopinionated frameworks) The Angular team absolutely knocked it out of the park with this feature.

Angular CDK

Screenshot of the Angular CDK docs page

Alongside Angular Material is a super awesome little package called Angular CDK. CDK stands for Component Dev Kit, and it is an incredibly handy package for helping you develop some of the more complex components an application requires. They're marketed as "behavior primitives" that you can use to build your own branded components.

Building buttons and input fields and such are fairly straightforward for people building component libraries, but there are other components that are much more complex such as modals, accordions, data tables, drag and drop, trees, and more. Rather than building all this yourself or relying on libraries that style these components how they want, Angular CDK gives you ways to very easily build your own complex behavioral components that you can style easily to fit your company or project's branding. Not only that, but these components are often much more accessible than components you would build yourself. As has been the theme with this post, Angular CDK helps you save a ton of time by having these abstractions built out for you so you can worry about the look, feel, and implementation of your components rather than the more complex details such as positioning, scroll behaviors, etc. It has saved me an enormous amount of time and complexity when building my components. If you're building with Angular, even if you don't use Angular Material, you should absolutely use Angular CDK.

Dependency Injection

This is a hot topic for some reason, but Dependency Injection is another huge reason why I love to use Angular. It allows me to not have to worry about defining my own patterns for singleton vs factories. Instead, Angular's Dependency Injection tooling makes it exceptionally easy for me to provide the dependencies I need, anywhere I need them, and to do it in an easy manner. Rather than have to instantiate a service in a component, I can simply inject my service and Angular's Dependency Injection will ensure I am given the correctly instantiated service, like so:

// Some service I've defined
export class MyService { /* ... */ }

// Some component in my app
@Component({ /* ... */ })
export class MyComponent {
  constructor(private service: MyService) {}
Enter fullscreen mode Exit fullscreen mode

The other huge benefit to Dependency Injection is for better testability. Automated tests are something that I consider absolutely vital to the success or failure of a product and the team that builds it. Dependency Injection in Angular makes it incredibly easy to test, mock out, and handle dependencies external to the unit of code I'm testing at the moment. Consider the above component. To mock a method I simply need to inject the correct dependency and then utilize Jasmine's spies to mock out the method.

describe('MyComponent', () => {
  let service: MyService;

  beforeEach(async () => {
    // Initialize Angular TestBed
    await TestBed.configureTestingModule({
      declarations: [MyComponent]

    // Inject MyService for mocking
    service = TestBed.inject(MyService);
    // Mock out `sayHello` method
    spyOn(service, 'sayHello').and.returnValue('Hello World!');
Enter fullscreen mode Exit fullscreen mode

It makes working in large complex codebases much more trivial, and makes testing vastly more simple. Are there downsides to Dependency Injection? Absolutely. No matter what pattern you choose, there are always going to be tradeoffs. It comes down to what tradeoffs you're willing to make in exchange for the benefits you consider most valuable. For me, Angular's Dependency Injection is one of the main reasons I choose it over other frameworks.


In case you've forgotten by this point, I'll reiterate one more time that this post is incredibly biased and entirely opinion-based. I absolutely love to use Angular, it's my framework of choice for side projects, and I believe it's an excellent choice for many of you as well. That being said, I absolutely would argue that it's not a good choice for many others. When it comes down to it, you need to weigh the pros and cons of each framework, decide what tradeoffs you're willing to make, and choose based on what you decide. For many of you that's going to be React, or Vue, or Svelt, or Stencil, or Ember, or heck maybe even Backbone. And that's absolutely okay.

I wanted to write this article to provide perspective to why I personally choose Angular over another framework. Not to provide more fodder for the "framework wars" or to bash on another person's choice. I will always say that the best framework choice for a project is the one you or your team is the most familiar with that will help you be the most productive and provide the fewest tradeoffs for what you want. In fact I love to read other peoples' completely biased articles on why they choose their framework (or library or text editor or whatever) and I enjoy celebrating their success and happiness over what they've chosen, while I enjoy what I've chosen. If there's anyone else out there like me who chooses Angular for their side projects, I'd love to chat in the comments about what your reasons are! And if you want to bash Angular or another framework for it not being as good as Framework X or Y, I humbly request you save those comments for the posts that encourage it. ❤🌈

Discussion (22)

oniichan profile image

I like Angular because it's opinionated and because of the directives, the same with Vue. I dislike React because it doesn't has directives and you have too much freedom, and it uses css in js, which makes no sense to me.

dgreene1 profile image
Dan Greene

You don’t have to use CSS-in-JS with React. In fact, most people use standard CSS Modules (just like I think Angular uses).

valeriavg profile image

I respect opinions that are diametrically opposed to mine. In fact I believe that diversity is a very good thing and not only in tech. With that said, it hurts me to see how the option to not use any framework at all simply became not an option. A framework, architecture or any sort of abstraction layer can and should be chosen or (blasphemy!) created for a particular project. After all, every programming language has it's own ways of doing things, limiting opinions and providing easy solutions for common problems.
But the higher the level of abstraction the less understanding you have of what actually is going on. This makes things harder to debug, fix and optimise.
Having said that, I agree that choosing a framework based on what you know best is wise. But by knowing I mean a deep understanding of how it works, what it can and cannot do and why. Which is always easier with your own code or a third-party code with the smallest possible scope.

johnbwoodruff profile image
John Woodruff Author

Thanks for the comment! I actually completely agree that no framework is just as valid of a choice, and one that I’ve utilized on occasion. Honestly not including it was simple oversight, since the post was specifically about why I chose this framework for side projects, and a natural comparison is other comparable frameworks. But thanks for bringing up that no framework is a totally valid option as well! I 100% agree with you! 😊

steveblue profile image
Steve Belovarich • Edited

Been working a lot with React, Vanilla JS and Web Components lately and I honestly miss Angular for all the reasons stated above.

It’s not trivial to maintain build infrastructure for modern JavaScript applications, but Angular CLI makes it so easy!

I’ve often wondered how many of the ideas in Angular were inspired by GWT, i.e. class Decorators and Dependency Injection. It would make sense for the Angular team to provide a similar interface to GWT if they wanted engineers at Google to adopt Angular over GWT and then lean so hard into these concepts while the rest of the JavaScript community was going the way of functional. Functional is OK, but unlike classes I find functional architectures like React Hooks to be a barrier to entry in JavaScript for people coming from other languages. Angular has stood the coarse, while React has changed dramatically over the years, causing a lot of friction within that community.

You’ve made your bed, now lie in it.

johnbwoodruff profile image
John Woodruff Author

It’s crazy to me how much mental overhead goes away when using Angular especially with Angular CLI. Things I had to worry about with any other technology that are simply taken care of by the CLI. It’s pretty great.

Thanks so much for commenting!

iainfreestone profile image
Iain Freestone • Edited

" I, John Woodruff, choose to use Angular in personal projects small and large."

That is all that needs to be said. Choose what you are happy with. Its not a competition. Best of luck

andreidascalu profile image
Andrei Dascalu

This is a place of discussion and reasond and point of view are important.

johnbwoodruff profile image
John Woodruff Author

Agreed! That being said I also love hearing what people love about their choices. (From a non-confrontational perspective haha)

lonelymoon profile image
Hung Luong

I still remember the first days I dipped into the deep waters known as frontend development. It was literally the same as that joke article "How it feels to learn JavaScript" or something I read back then. Angular was a godsend as I instantly understand everything that need to be done to put stuff on screen and be done with it.

brunnerlivio profile image
Livio Brunner

100% agree with your point on "opinionation". The beauty of Angular is that because of its similar paradigms you'll find it so much easier to on-board to any other Angular project.

In contrary, for complex React application it's like the wild-west; so many different approaches and libraries which may or may not be used, depending on the opinions of the team who maintains the app.

On the flip-side -- and that is just fundamental differences of Angular vs React specifically -- it always bugged me how much overhead I need to create for a single component. With React it's as simple as creating a function in a simple TSX or JSX file. I usually see that in Angular apps I create way less (stateless-) components because of that.

I also prefer React JSX over Angular template engine. It just feels so much more "native" to use a "syntax sugar"-ed JavaScript than a completely custom HTML engine.

I think StencilJS nicely solves both of these mentioned issues by offering Class & Functional components as well as JSX templates.

johnbwoodruff profile image
John Woodruff Author

Thanks for the thoughtful reply! I absolutely love Stencil, I’ve actually written a fair amount about it here in! 😂 I will say though that I don’t personally use Stencil for anything other than component libraries/design systems, and it comes down to the fact that I’m way more productive with Angular when building large apps. (Again, entirely opinion based)

mayvid14 profile image

Angular was the framework I started my career with, and maybe because of that I love it. It has (almost) everything you need to build an application. From SSR, to PWA, to drag and drop support. I have found myself struggling with other frameworks due to this fact.

As time passes by, I may not be using Angular on a day to day basis, but it remains my first choice when it comes to personal projects 😅

johnbwoodruff profile image
John Woodruff Author

Exactly, while I use a variety of other frameworks and technologies, my personal projects are basically always Angular! I love it too much to choose anything else.

dgreene1 profile image
Dan Greene

You can easily mock/spy your dependencies without dependency injection since Jest has module spies. That way you don’t have to worry about a bunch of boiler plate just to be able to mock a dependency.

There’s too much cruft with dependency injection (in my opinion). And it makes debugging challenging.

walkingriver profile image
Michael D. Callaghan

Well said, John!

johnbwoodruff profile image
John Woodruff Author


hasnaindev profile image
Muhammad Hasnain

I agree with your conclusion. Choose the tool best fit for the problem you're trying to solve.

johnbwoodruff profile image
John Woodruff Author

Thanks for the comment Muhammad! Yep, I’m very much a proponent of this mentality!

stephenradams profile image
Stephen Adams

Great post John. Totally agree with you 👍

johnbwoodruff profile image
John Woodruff Author

Thanks Stephen! I appreciate the comment!

tojacob profile image
Jacob Samuel G.