AngularJS, the legendary legacy framework

AngularJS, the superhero framework

Okay, so I’m late with this article. But I can’t start off my series about front-end web frameworks without addressing the obvious elephant on the web. AngularJS. I’ve used it. A lot. And I have somewhat of a love/hate relationship with it. Here’s my unfiltered opinion about it.

The pro’s : fast and easy

Angular basically lets you create a domain specific language by extending the HTML set. It looks and feels easy when used right. If you have a designer who’s great with graphics and usability, but can’t program to save his or her life - then here’s your savior. It abstracts a lot of implementation away into familiar HTML-ish tags. No need to write code for people who care only about usability and looks.

Angular is easy to pick up. Basic usage of angular is easy, and after a couple of hours working with angular you’ll be able to set up single page applications. The framework is (was) unopinionated, and with the flexibility dependency injection gives, there are a lot of ways to achieve what you want to achieve with this framework. This also is one of angular’s downfalls however - more on that later.

Development and prototyping in angular is really easy once you’re set up. Adding functionality can be done super fast. If the functionality you want isn’t included in the standard set of services the angular team offers you, then it can probably be found in the immense ecosystem around it. Once you’ve created your first project for prototyping, new prototypes can be built blazingly fast.

The cons: hard to master and unopinionated

Although angular is easy to pick up, it’s learning curve is steep. So steep, that architecture of large apps should probably be done by your most senior front-end dev. Hence it’s main drawback is that it doesn’t work that well for large teams on deadlines with members of varying skills who don’t do test-driven development or proper peer-review. Which, admittedly, is more of a business process issue - but that’s exactly the point. You should not be able to cut corners when it comes to speed vs. quality. A member of a team that’s pressed on time will always cut corners leading to quality degradation. If you can’t do it properly, then reassess the situation and reevaluate.

Which brings me to the unopinionated part. Up to 1.5, angular was mostly unopinionated. Sure you could find awesome guides by John Papa and Todd Motto on how you should structure your large apps, but the framework didn’t enforce anything. In any scenario where different team members have to add things to an existing software package this can, and will, lead to exorbitant wild growth of coding styles, and pieces of code with duplicate functionality. (Yuck!)

Now, angular 1.5 added components and one-way binding. They come with a strong recommendation from the angular team (read: opinion) on how to use them. Which basically boils down to this:

State is passed down, state mutation is done from the top down. And for for f*ck sake, don’t two-way bind everything.

And last but not least. Because the framework started out unopinionated, the only way to get project scaffolding in fast, was to use your very own yeoman generator or invent some insane snippet library. Which is okay, I guess - but I’d like to just be able to scaffold an app by using code provided by the framework’s creators, so the intention of how it should be used is clear and there’s a solid starting point from which to work.

Conclusion: Support the legacy apps you have, try to prototype in another framework

AngularJS was great for what it was. And it’s ecosystem is still one of the largest I‘ve seen. So if you need to provide a prototype pronto, you can still use AngularJS. But if you want a speedy front-end which scales well, and can be mastered by new developers in an insignificant amount of time, you should start looking towards the horizon and perhaps focus on familiarizing yourself with another framework. Which one you want depends on your use case;

If you need clear opinionation, and you’re building long-term enterprise-grade applications within a team setting (and are willing to drop some fancy features for now), consider Ember.

If you need a rapid prototyping full-stack solution, consider Meteor

If you need a lightweight replacement for AngularJS, consider using Vue.js for view-rendering.

If you need rapid prototyping for front-end and bleeding-edge features - consider React with Redux or Angular. (“AngularJS” is angular 1.x and “Angular” is angular from 2.x onward)