We’re in a golden age of client apps. Front-end frameworks for web app development from the obscure to triple-A abound. Therefore, there are many great choices for tooling to get your next app to market as quickly as possible with a few issues and hang-ups along the way as possible. Today, we’re going to explore why you need Angular, some of the pros and cons of Angular, and see if the benefits of Angular outweigh some of the other choices out there.
Iterating on a Good Thing
But it had its shortcomings to be sure. Dynamic select boxes with many options could commonly choke out the digest cycle. This made developers confused about what exactly constituted a directive, service, or factory, and the lack of a standardized build chain often left a great many problems to solve outside of actually writing the application code. The shortcomings were so great, in fact, that the Angular team learned from the experience, vastly improved their approach to the framework, and made a clean break beginning with version 2, re-titling Angular as AngularJS and moving forward with the plain Angular name.
Now Angular is characterized by clean components that work together to build an app, not easily-bloated controllers that rely on scope and digest, and a baked-in CLI and a preconfigured webpack-powered build system that take all of the guesswork out of the app overhead.
Because of the big fundamental differences in application architecture with Angular versus its earlier incarnations, migrating a web app from AngularJS to Angular is not necessarily straightforward, but because Angular has kept some of the same building blocks like directives and services stitched together with easy-to-understand dependency injection, migration is definitely not the ridiculously convoluted process it could be. Additionally, there are a great many well-written articles like the official developer guide at angular.io.
One of the biggest benefits of Angular is its speed of getting new apps to market. Angular CLI makes scaffolding new components as simple as a quick terminal command and the build pipeline comes already configured with each new app. So you’re more free to jump right into writing app code and waste less time making decisions on how to compile your app or worse fighting with a one-size-fits-all task runner to make it work for you and your app.
The counterpoint to this is initially getting the hang of Angular. Like it’s older brother, and to a greater extent in most cases, Angular is a very opinionated framework. Sometimes there’s really just one “right” way to get something done, and because it isn’t always incredibly intuitive, you can spend a little extra time going over the docs or troubleshooting a less-than-helpful error message. But there are thousands of helpful answers and examples on StackOverflow and once that’s nailed down, you’ve got a great example for how to proceed next time. So in that respect, it’s no different than any other front-end framework out there today, and chances are if you’ve had any exposure working with angular.js for web or migrating to AngularJS, you’ve got a good foundation for the “Angular way of thinking.”
With the restructuring introduced in Angular 2, the team made a great decision to build apps with an idiomatic ECMAScript-style group of components and modules. Components can be a form, a single control, or a whole page. It can take a little trial and error to find what level of granularity works best for you and your team, but once that’s sussed out, it feels very natural to concentrate on a single concern at a time. How many times have you written or found what look like silly or unavoidable bugs somewhere in a thousand-line controller file? If that controller had been composed of a set of minimally-concerned components, the developer working on them would have been more able to cleanly concentrate on a single task at a time, not to mention the benefit that lends to testability. It’s nearly impossible to properly test a massive controller file with re-used business logic and hacks that hook directly into $scope, but Angular’s CLI stands up new components complete with Jasmine spec files, setting you up for testing success from the start.
Also, by breaking down an app into multiple smaller components, two or more developers can work simultaneously on a single feature in separate components and enjoy a greatly reduced risk of stepping on each other’s toes or suffering confusing merge errors on check-in.
If you’re trying to sort out the best front-end framework for your next app, give Angular a try. All the benefits of being sponsored by big-name organizations like Google and Microsoft and its increasing maturity in the browser app space make it a clearly good choice for any shop. Its willingness to learn from where its been, its speed to market for even less seasoned Angular or front-end developers, and its clean component-driven architecture are all bright feathers in its cap.