Choosing a front-end framework is no small task these days. There are a lot of options out there, each with pros and cons. When I decided I wanted to move to a “next gen” framework, I surprised myself by going with a framework that I initially had a lot of negative feelings about: Angular.

In this post, I’m going to explain how Angular won out over the competition, including an early favorite of mine, Aurelia.

[more]

Analysis Paralysis

So here I am, in 2017, and I’m about to begin work on a new greenfield project. I have a “starter kit” of sorts that I use to bootstrap my new projects, but it’s old. It’s built on a combination of AngularJS, Bootstrap (with LESS, not SASS), and ASP.NET MVC.

So yeah, it’s pretty dated. It works, but I decided it was time to update things.

The good news is that there are a lot of options for everything these days, from UI, to server-side, to data storage… the possibilities are literally endless.

The bad news is that there are a LOT of options out there for everything these days!

I quickly found myself succumbing to analysis paralysis, constantly re-evaluating my options, questioning my decisions, and just generally feeling like a ship without a rudder. I was getting nowhere until I took a step back…

What I Want

I needed to decide what was actually important to me, and define what I would like from my front-end framework.

Low Ceremony

I’m a consultant. I get paid to deliver business value. Any time spent not delivering value is money lost. It’s one of the reasons I’ve stayed with my existing new-project-bootstrap kit for so long: it lets me get up and running very quickly, so I can immediately start delivering value.

To that end, anything that I choose for my new kit needs to be low ceremony and low friction. The less time I spend dealing with boilerplate noise, the better.

Well Supported

I don’t want to spend a lot of time trying to figure things out. I don’t have a ton of time to spend blazing a new path.

Every technology has sharp edges and pain points, but I’d like to know where those pain points are before I encounter them myself. And I’d really like to know ahead of time how to deal with those pain points. I want the happy path to actually be a pit of success.

The tools I use need to be well support both by their creators and a community of developers. I want to be able to build on the work of a thriving community.

Rapid Development

This probably goes without saying, but I want my tech stack to enable me to build things quickly. I want fast turnaround times.

When I make a code change, I want to know quickly if I’ve broken a test. I want to be able to test it out in a browser without feeling like I should go and order a pizza while I wait. I want to go from idea to working code in as little time as possible.

That also means I want out-of-the-box solutions to common problems. The more pieces I can plug together to build a solution, the fewer things I have to create myself.

Beautiful UI Options

Last but certainly not least, I want something that has nice UI/UX packages I can leverage. My design skills consist of “I can tell you what I don’t like…”, and that’s about it.

So those are my requirements. Which tools fit the bill?

The Contenders

As I said, there is no shortage of options these days, and I didn’t consider every possible tool out there. Here are the ones I gave serious thought to:

Aurelia is Rob Eisenberg’s baby. In its own words: “Aurelia is a JavaScript client framework for mobile, desktop and web leveraging simple conventions and empowering creativity.”

Angular, the framework that everyone has heard of! I don’t think this one needs an introduction.

React is a framework from Facebook for building UIs. It popularized the HTML-in-JavaScript syntax, JSX, and is crazy-popular these days.

Vue.js is the scrappy newcomer, and lots of people seem to enjoy working with it.

I spent a good bit of time considering these four before I eliminated two of them.

The first framework I eliminated was React. I’m sure it’s a fine framework, but after reading up on it, looking at samples, and doing a quick survey of the UI options, I decided I really don’t want to work in React. I want a more prescriptive framework that does more of the heavy lifting for me. With React, I felt like I’d be cobbling together a lot of different pieces to build my own solution.

The next framework I eliminated from consideration was Vue.js. I didn’t see a ton of mature-looking UI frameworks and/or theme kits built with Vue.js, and overall, I just didn’t feel like it was ready to build my “consultant framework” on top of.

That left two contenders: Aurelia and Angular.

Aurelia

Ahhh, Aurelia. I’ve been a fan of Aurelia since Rob Eisenberg first announced it.

It has many of the things I’m after. It’s low ceremony, and relies heavily on reasonable, default conventions to wire things together.

It enables rapid development. The Aurelia cli tool is nice. It’s the little things that set it apart. Like if I screw something up, I don’t have to notice it in my browser or in my console window. Instead I get a toast notification on my desktop. And it feels fast, too. I didn’t benchmark it or anything, but it certainly felt snappy.

Buuuuuut…. it’s not without some downsides.

First, I struggled to find a good UI/UX library. There are several options in the form of bridges to other UI frameworks, but none of those were as polished or complete as what I was looking for. That’s a big problem for me given my lack of good design skills.

Second, its development is much slower than some of the other major frameworks out there. Just check out Aurelia’s Github pulse for the last month…

And compare that to Angular’s:

To be completely fair, Aurelia is broken up into many smaller pieces, and some of those pieces have had significant activity recently, but nothing on the scale that Angular has seen.

And that leads to the next problem: lack of adoption, and therefore, community. Aurelia adoption is low, and from my past experiences, that usually means I’m going to find all sorts of little landmines, edge cases, etc. As a consultant, those types of things are performance killers, and I don’t have time to deal with them.

Angular

In the end, I decided to go with Angular, even though I really didn’t want to… at first.

“Angular: The Framework Everyone Loves to Hate”. That could seriously be the official tagline.

Angular is the target of a lot of negativity these days. And it’s not completely without merit. The Angular team stumbled badly when they announced Angular2, and they continued to stumble with confusing messaging around migration from AngularJS. They would have been better off to give this new framework a new name. But, alas, they stuck with Angular, for better or worse. Anyway…

So let’s start with the problems here. First, good luck Googling for Angular-related things! If you’re looking for a solution today, you’ll have to filter out results for AngularJS (totally different framework!) and Angular 2, because the current version is actually Angular 4! There are breaking changes between Angular 2 and Angular 4, but more importantly, there are better ways to address some common scenarios in Angular 4 that weren’t available in Angular 2.

So yeah, Googling for Angular-related things is painful.

And that leads in to my second complaint: there are still a lot of breaking changes, and a lot of things that are being added to the framework, with each release. Rapid improvement is usually good, but as a fellow developer said, when it comes to frameworks, you have to let things bake for a bit so that people have a solid foundation to build upon. I still don’t think Angular is at this point.

My final complaint with Angular is that it is high ceremony. There’s a lot of boilerplate for an Angular app itself, not to mention a lot of overhead for every component you create. TypeScript itself is also more verbose than what I’m used to with JavaScript.

That said, I do find that the Angular CLI does a satisfactory job of dealing with a lot of that ceremony for me. When I combine that with the right VS Code extensions (more on that in a future post), I find that the ceremony doesn’t really slow me down. In fact, once I got used to TypeScript, I hardly noticed it anymore.

And that leads us into the “pros” for Angular.

The CLI

First, there’s the CLI. I love that I don’t have to write and maintain my own build scripts anymore. I’m so glad we’re finally back to this point on the front-end! Angular’s CLI has all the features you’d expect, including smart generators for all the common Angular “things” you might create. One of the cool things it does is actually wire things up for you automagically. When you generate a component in a folder that contains a module definition, the CLI will update the module definition for you.

To be completely fair, I did find Aurelia’s CLI to be both more helpful and more stable than Angular’s. There are still times when ng serve stops working due to one cryptic error or another, and only killing and restarting the task seems to fix it. It works fine most of the time, but it isn’t perfect.

TypeScript

The second major “pro” is TypeScript. I’m eating some crow to admit this, but I actually enjoy using TypeScript. The improved Intellisense experience over regular JavaScript has really boosted my productivity.

It’s prevented me from making stupid typos that would normally have not been caught until my specs ran or until I actually tried to run my app. That doesn’t sound like much, but we’re talking about shortening the feedback loop from seconds (with either automated or manual testing) to instant feedback. I underestimated how big of a deal that was.

It’s also helped me find what I’m looking for quickly and accurately. In pure JavaScript apps, both Visual Studio and VS Code would give me reasonable suggestions when I was trying to remember what the members on an object looked like, but it was far from perfect, and I’d often have to jump over to the object definition to find what I was looking for.

Using TypeScript with the right VS Code extensions allows me to find what I’m looking quickly and accurately. That’s been a bigger productivity boost than I would have thought.

Support

This is a big one for me: Angular is very well supported not just by Google, but by an active community of developers, too. There’s a lot of activity all around, and I’ve yet to feel like I’m blazing completely new trails while using Angular.

Yeah, I know I said that googling for anything Angular-related was a pain, and that is true, but with a little patience, I’ve been able to find accurate, up-to-date solutions for any issues I’ve run into.

Lots and Lots of Templates

The real clincher for me was the abundance of UI templates and frameworks for Angular. There’s Angular Material, NGX Admin, Material Design for Bootstrap 4 (Angular), Ionic (good for mobile, and getting better for desktop apps), and my favorite of the bunch, Creative Tim’s Angular Dashboard. There are plenty of others out there, too!

For a non-designer like me, having all of these prebuilt UI packages and themes I can lean on is a big plus, and that’s what ultimately led me to choose Angular over the alternatives.

Final Thoughts

At the end of the day, I’m paid to solve problems, and I need to be able to do that quickly. I truly enjoyed the time I spent prototyping with Aurelia, but Angular won out because of its larger community, abundance of UI options, and because of the nice tooling you can get with VS Code. I still plan to keep an eye on Aurelia, and I hope it becomes a better fit for me in the future. But for now, I’ll be sticking with Angular. Expect to see more blog posts on that topic in the not-too-distant future. ?