Why you should choose Angular for your next front-end project
I wasn’t originally a front-end dev, I usually do a lot of back-end/API work with C#, Go, Node, or Python. A few years back I was thrown into a full-stack role when I moved to a new company. I was tasked with creating an internal-facing solution that had user management, IM capability, note-taking/sharing capabilities, and a whole bunch of other stuff. This was really my first big introduction to front-end development, I had done some front-end stuff here and there, but nothing this extensive. At the time I had AngularJS at my disposal, which threw me into the Angular world head-first. I can still remember my excitement around the new Angular release (Angular 2), and it hasn’t faded much since.
I am happy to say that I have been working with Angular since it’s inception in 2016, and I am really glad I chose this framework. In this article, I’ll tell you how Angular can help make your next front-end project a breeze.
Short Learning Curve
If you’re new to front-end development the number of frameworks can be overwhelming. I won’t delve into any other frameworks, as that would be out of scope, but I will say that choosing Angular will make your life a whole lot easier. Of all the front-end frameworks available, Angular will probably take the least amount of time for you to get up to speed with. There are a ton of factors that go into why Angular has a short learning curve, many of which I’ll talk about later.
Mature CLI
The Angular CLI is one of those things that give Angular its short learning curve. The learning curve can be shortened even more with 3rd party tools like the Angular Console (regardless of whether you’re new to Angular or not, you’ll love this tool, but it is not necessary), that gives you a visual tool for the CLI. One of the greatest things about the CLI is that it will take care of anything you need to do from creating a new Angular project or creating services, components, or whatever else your project needs. One thing that a lot of people love about it is that for each new component, service, pipe, etc the CLI also creates an associated test for it. The CLI also gives you a standardized way to run all your tests as well. This gives you the added flexibility to know that each new file has a test and you can update the tests at whatever stage of development you’re in. I could write a whole article on the CLI alone, but in the interest of brevity, this is all I’ll say for now.
Angular Standards
The CLI has another added benefit, it is very opinionated. For some people, this is a problem, but it is designed that way to help you. When you’re using the CLI Angular automatically imposes it’s own set of standards to your project, basically doing things the right way for Angular to get you started. This will help you avoid a ton of mistakes, especially when you’re hooking up a project. This really shines when you’re working with a team, or onboarding a new team member. If they’re familiar with Angular they’ll already know their way around your project and they will be productive in a much shorter time.
TypeScript
Angular uses TypeScript natively, which was a massive advantage for me. If you’re coming from a background of using typed languages, TypeScript gives you a way to apply a brilliant type system to your JavaScript code. If you’re a .NET person, you’ll definitely enjoy this. Even if you have never written a piece of code in your life and you wanted to start out, TypeScript is a pretty good first language to use. It will get you familiar with a lot of OOP principles that are directly transferrable to other languages that JavaScript would otherwise not.
Component Libraries
This is not unique to Angular, all frameworks have plenty of component libraries that you can use, however, the Angular team has created Angular Material, which is one of my favorite. If you’re not familiar, I’ll give you a little bit of history. In 2014 the good people over at Google created a design language called Material Design. If you’ve ever used Gmail, you’ve been exposed to material design. It has gained a ton of popularity since it’s inception. Angular Material is Google’s unique implementation of Material Design for Angular, which I think is awesome. It encapsulates and standardizes most components you would need to create any kind of site or app. If it doesn’t have a component you may need, which happens, you can easily create it using what they give you.
Ivy
Angular Ivy is a brand new compiler and rendering engine for Angular. It hasn’t fully shipped with Angular, but you can opt into using it now. The really cool thing about Ivy is that it changes how Angular works under the hood without really affecting how we build Angular applications.
Incremental DOM
I won’t go in-depth about Incremental DOM, but if you want to get more in-depth this is a great article that takes you through incremental DOM and how it differs from virtual DOM, this will basically be the TLDR version. Basically virtual DOM uses a ton of host memory creating and diffing DOM trees. This is obviously not good for mobile performance. Incremental DOM was designed to use as little memory as possible while still rendering changes quickly. In fact, incremental DOM uses almost no memory. Ivy will only use memory when DOM nodes are added or removed and the amount used is directly proportional to the size of the change. This results in massive memory saving and better mobile performance.
Bundle Size, Build Time, and Tree Shaking
Along with incremental DOM, Ivy also has some incredible tree shaking capabilities. Tree shaking basically just removes unused bits of code making your bundle size smaller. The cool thing about Ivy is that using incremental DOM is also tree shakable. Angular has traditionally had much larger bundle sizes than other frameworks, but with each iteration, it gets smaller. The same can be said of build time.
Is Angular Perfect?
I always try to be honest, and while I love Angular, it is not perfect. While I think it’s better than other frameworks, perhaps these things may be deal-breakers and it’s better to know these things upfront.
Build Size
If you’re using Ivy, you can probably improve your build size around 15–20%, but it’s still a little large when you compare it to other frameworks. The larger your build size is the slower your first render is. This is going to continue to improve as time goes on, but as it stands now, this is definitely Angular’s weak spot.
Standardization
Depending on the kind of developer you are this can really be a double-edged sword. Personally, I enjoy the fact that Angular is opinionated. I can look at any Angular project and get a really good idea of how everything works at a glance. However, if you like doing things your own way or you simply don’t like the Angular way I can see how that would be a thorn in your side.
Developed by Google
Angular is made and maintained by Google. As we all know, Google engineers are usually known for being exceptional. However, they do have a penchant for just giving up on products. AngularJS is a prime example of this. Some may worry that Angular could end up the same way, but I don’t think there is much need for concern. One of the main reasons I’m not particularly bothered by this is that in creating Ivy they rebuilt how Angular works under the hood but made sure that it doesn’t affect how users are writing Angular apps. I am quite hopeful that Angular will be around for quite a long time to come.
Finishing Up
No matter your skill level, I hope that you decide to give Angular a try. I think it has some incredible features, and they continue to get better. If you’re interested in learning more about Angular, check out these resources:
