The Toolchain and Standards
I’ll be honest - I really like the Angular CLI. For those that haven’t interacted with Angular before, a lot of the simple things you might do in a frontend framework (Adding a component, starting a project, adding services) can be done via a command line interface. It just feels slick and powerful, and takes away a lot of the mundane boilerplate work. It feels reminiscent of working with something like Razor pages in a .Net MVC WebApp - which is maybe why I like it. I enjoy the experience of a computer doing the stuff that computers are good at, letting me focus on what I want to produce - especially in the context of frontend work.
Less Time Researching
It’s Not All Roses
The convenience of Angular does come at a cost. Using other npm packages not specifically built for angular can be a bit of a wrestling match. For example, I used Leaflet in an Angular project, and getting that to work as a component was something of a pain. This is also reflected in that the ecosystem is much smaller - there are a lot less Angular specific packages. I think this could be a consequence of Angular’s enterprise aspirations - where there tends to be a lot less sharing of code. Finally, Angular is built with specific use cases in mind - if you’re not building a Single Page App, you might find yourself in sticky waters quite quickly. There is also a lot of boilerplate code involved in Angular - probably as a consequence of the CLI populating a lot of it for you.
However if you’re primarily an enterprise backend developer, used to working with languages like C# and Java, I think you’ll find the framework familiar. This is less to do with things like Typescript, and more to do with the fairly rigid documentation and way of doing things. It’s also a nice framework to pick up when you just need to get an interface on a page, especially if you’re expecting a lot of interactivity.