Giving Angular another try

I’ve been playing with the latest Angular version for the last couple of weeks and I’m enjoying it. The last time I touched Angular 2+ was in 2016 on an Ionic mobile project and before that, only had experienced working with the now called AngularJS. The current version (7) looks great!

I took two introduction to advanced courses on Udemy and even though they were had good materials, they were more like a video version of the Angular documentation and, in this cases, I do rather reading the documentation then watching the explanations. Written content allows me to search quickly and even jump into the contents I want to focus more. Lately, I found a good material from Todd Motto on Ultimate Courses that I could go deep into front end development using Angular. Got a serie of courses from Fundamentals to Pro, which I’m finishing and about ngrx store that’s still pending.

I must say that after all these years without touching Angular it felt nice to play with it again. Even the Typescript part seems to be more smooth now and I really think that Typescript suits well to developing using Angular.

It’s hard to compare frameworks and libraries and I’m not going to do that. We all know that a framework/library decision depends on a lot of things that should be considered beforehand such as project type, team knowledge, team size and etc. I’m mentioning this because during this period that I’ve learning Angular again I tried to avoid any comparison with React or Vue that I’ve previously learned or read about.

After all these years working with web development one thing that I learn is not to advocate softwares and libraries. Mostly because there’s no silver bullet and, as said before, it must suit the project and team needs. That said, I, personally, — not that anyone cares — am betting on Angular again. Although it seems I’m might be going against the flow, I see Angular as a fantastic framework for frontend development – specially if you are start from the ground -and some of the main reasons I’ll try to point out below.

Typescript was a good call

Even though Typescript is not JavaScript, it has its learning curve and is not broadly adopted, I still think it’s the way to go to write output JavaScript. If you have an OOP background from any other programming language you might be familiar with Typescript. As a strong typed programming language by default, it makes the code more descriptive IMHO, and avoid, on compilation time, errors of syntax that in Vanilla JavaScript you’ll need a linter. Also, the compiler takes care of the output targeting and, hence, its polyfills.


All the fundamental parts of a frontend application are managed by Angular without the need of a 3rd party library: forms, routing, lazy loading, internationalization and http client for instance. Although RxJs isn’t part of Angular team, it’s integrated smoothly and ready to use. Same for testing. One benefit out of it is that it doesn’t have dependencies for the basic stuff and you shouldn’t be worried about compatibility among them.

Dependency injection

I was missing DI lately. It was one of my favorite things in the AngularJS version. Although you might say it’s not needed, I certain it helps readability and code reuse through Separation of Concerns. You will survive without it, specially on small apps, but you definitely see the benefits of it when writing large apps in mid-largely teams.

Template-driven and Reactive forms

Although it has two approaches to implement forms, I rather use the Reactive way as it doesn’t rely on the markup as the source of truth. When working with forms, it’s easy to get your code way too verbose and, as far as I see, Angular had managed that well. It’s simple to create a form, populate and extract the values out of it. Even the validation system it’s quite simple. Forms are they base for a lot of apps and having a strong background to implement it certainly it’s an advantage.

Components scoped-style

Dealing with CSS in large project and teams were never an easy thing to do. Specially when it depends on having a lot of global CSS declarations. I really liked how Angular solves by adding a hash that scopes the component styles. It’s safe do write component specific CSS without worrying about breaking other component’s style that you don’t even knew about it.

Style Guide

Even though developers (or architects) likes to write their own style guide, I fail to see a real advantage of it. To be fair, most of the time the one I saw they were created due either to the lack of an official one or the official one suggested way too many options to do the same thing. One issue with having your own style guide is that sometimes the responsible person leaves the company and the team is left out with a style guide they have to follow without a clear benefits. At this moment, it’s possible that developer starts to write code using their own code preferences. The results is often an inconsistent code. I see Angular having a strong definition of their style guide and even though it’s not mandatory to adopt it, why wouldn’t you? The team will even have a CLI tool to keep the styles on track.

That’s not all

Angular is a solid frameworks that’s aiming to help you to write solid frontend apps. Those were the topics that got my attention as of now, take a look at it if you are interested and find of it fits your project.

I recently joined a company as a Senior Frontend Developer where the frontend team is using Angular and I’m pretty excited about it.

As I said before, there’s no silver bullet for software development, however, there are some frameworks/libraries that will suit your project and team. Personally, I’m betting on Angular.

Published by Daniel Salvagni

A Brazilian front-end developer currently based in Berlin.