I won't be using Angular for my next project...and neither should you.


I don't know about you, but I've been incredibly impressed by the community that surrounds the Angular project. They have worked tirelessly over the years to help others by giving excellent guidance on best practices. I say "they" because I've never been able to truly embrace the framework, it was more like being dragged kicking and screaming towards it most often.

They have been able to preserve the idea that Angular is actually a good framework to use, when fundamentally, it's broken in so many ways. Many stick their fingers in their ears at this point, and that’s fine – I actually have a tremendous respect for anyone willing to tough it out with Angular because more often than not, after a while, it will not be by choice.

That also doesn’t change the fact that Angular is still broken, and as much has been admitted by numerous core team members who have sunk tremendous effort in to improving these parts over time, only to be stonewalled by fundamental flaws in the original design. This was speculation and opinion for some time, but is now also evidenced by just how much is changing under the hood of the next version.

In my heart of hearts I really wish it wasn't broken, because something with this much momentum in open source circles doesn't come around very often. I know Angular has the likes of Google behind it, just like React has Facebook to push it, but let's be honest, regardless of the effort Google has put in, the community at large has been very effective at keeping the life support system that is labouring away underneath Angular alive and kicking.

All that aside though, I really think there are too many overwhelming reasons not to use the framework for my next project, and by that, I probably mean any of my projects in the future, and here’s why…

Angular 2.0 is on its way … eventually

This in itself should not be a negative thing, and should definitely not be a reason to avoid the current incarnation, but unfortunately the official the announcement was completely botched. Possibly because it happened too early, but I would say mostly because of the sheer volume of change coming to those already heavily invested in doing it “the Angular way”.

Perhaps the announcement was made as early as it was to take most of the sting out by the time it lands in our proverbial laps. That being said, even if they hadn't botched it, I'm not sure the outcome would have been very different. As was to be expected, it completely polarized the existing community while some of us just sat back and started heating up the popcorn.

Many ran around shouting that the sky is falling, while more experienced campaigners weretelling everyone to calm down. They themselves weren’t sure what was going on, but they were certain it was no reason to panic.

But after all the fuss, the final takeaway for me seemed to be that you're going to be using Angular v1.3+ for existing apps, and new apps will likely be built with v2.0, assuming you can be bothered to learn the “new Angular way”, and that you’re lucky enough not to have to target older browsers.

That’s a fair trade-off. I’m sure there will be a migration path in the long run, but having it sooner won’t change the fact that older browsers will need to be supported for a lot longer outside of fantasyland, and so migration will no doubt have to wait in any case.

But it was this news from Rob Eisenberg that jolted me straight back to reality.

At this stage I was still pretty optimistic that v2.0 was heading in the right direction, and that I may actually enjoy using it one day when evergreen browsers are all the rage. But it was this news from Rob Eisenberg that jolted me straight back to reality. He said all the right things and was incredibly diplomatic, but when a guy I've been learning from and whose work I’ve been following for the better part of a decade decides he's had enough, then that's when I sit up and read between the lines.

He’s a smart guy, and he’s made a decision that fits best with his vision for the future, and that’s fine. There are plenty of smart guys still whittling away on the new Angular code base so I’m sure it’s in good hands, but an event like this does send out tremors, and those are inevitably felt by everyone, and it most certainly has consequences.

But enough about Angular 2 – let’s talk about Angular today…

It’s like a cancer in your views

There, I said it. Every time I look at an Angular view, I’m reminded of those medical CGI close-ups of cancer cells growing alongside the healthy cells. It slowly invades, starting off looking rather innocuous with a couple of ng-*’s dotted around the place, and you ignore it, because it’s still doing what it’s supposed to do.

After all, this is not the first templating system to do this right? It’s been done before, we’ve all seen Knockout, Handlebars, Jade, heck even going as far back as Haml or classic ASP/JSP, and more are springing up every day.

You know something is wrong, you know where it’s happening, but a glass wall has been erected in front of you (ironically) called the view

I’ve done my fair share of putting logic in the view over the years, and as anyone with enough experience can tell you, it’s an ugly beast with sharp teeth, and it comes back to bite you, and it bites worst of all just when you decide you need to debug something about it. You know something is wrong, you know where it’s happening, but a glass wall has been erected in front of you (ironically) called the view, and no matter how many times you jab your grubby finger at it, you can’t reach through it.

Now perhaps the tooling is at fault – perhaps someone should build something that allows us to step into and debug our views more effectively than you can today. “Pull everything into custom directives!” I hear you say. Yes, that would be nice wouldn’t it? Ah, and then there’s that pesky $scope you keep passing around. I could keep going (and others have), but what it boils down to in the end is a really long winded game of chasing your own tail.

Every fix, every hack, every workaround, just leads you inexorably towards the next one until you finally decide to stop the madness, and just accept the trade-offs you’ve made so far and ship the damn product. Those trade-offs typically tend to be in the form of somewhat cryptic code or views, state passed around where it shouldn’t be, or perhaps even performance of the app as a whole.

Like a giant game of Whack-a-Mole, you smash one obstacle in the face only to have a couple more pop up, and eventually your arm gets too tired to care.

To be an effective Angular developer, you need to keep an arsenal of hacks, workarounds and special insider knowledge in your tool belt at all times. You become an Angular specialist, peddling your fixes to the highest bidder, or writing blog posts about the “right way to do XYZ with Angular”, only to have another tutorial pop up somewhere else contradicting your point because they’re optimizing a different part of the system – you just can’t win.

Juniors learning bad habits

Ask any junior developer who has used it briefly, and they’ll tell you that they absolutely love Angular. In this sense it’s like giving candy to a child. They love the taste of it, can’t get enough of it, and run around screaming because of all the extra energy they have. And when they hit a sugar low, as they inevitably will when using Angular, they scream for more sugar and so you come along and help them climb over the wall they just ran face-first into. What these juniors don’t realise, just like the children, is that too much sugar at once will give you a bad belly, and in the long run it’ll rot your teeth.

My biggest gripe about Angular today, is the number of bad habits being picked up by our junior developers from the plethora of bad information out there on the web. They are fairly new to JavaScript and web development as it is, and now we're expecting them to hack their way around a framework that is constantly getting in the way, rotting their minds with anti-patterns and workarounds.

The idea, that a framework is there to help not hinder, accelerate not slow down, is one of the many virtues claimed by Angular, but could not be further from the truth. There are a few out there that do deliver on this in my opinion, BackboneDurandalAmpersand and Mithril all spring to mind, and I’m sure there are others I’ve not yet had the pleasure of building something substantial with. All of these let you focus on your JavaScript, and get the hell out of your way.

hold on a sec while I pick up the parts of my brain that just exploded!

The very fact that an article exists which prescribes that you should be mindful of the order in which you write your HTML attributes in Angular to optimize performance and other quirks is staggering. I clicked the link expecting a good laugh, or possibly finding out April 1st had come early, but... hold on a sec while I pick up the parts of my brain that just exploded! The order in which you write your Html attributes is important when using Angular. Just say that sentence to yourself out loud a few times. Go ahead, I’ll wait…

UPDATE: I received a fair bit of feedback asking for examples in this area, some geniune, some not so much, so I decided instead of lengthening this already long article, I'd make another one for those interested: Take a look here.

It reminds me a lot of SharePoint

Let's not beat around the bush here - there is a metric ton of money to be made as a good SharePoint consultant. I put food on the table (and then some) many a year selling my soul in that game. In this respect, Angular is heading in the same direction – I see tons of job posting and consulting gigs crying out for solid Angular developers and consultants. I’ve even been tempted myself, to cream it while the going is good. Make no mistake, it's an excellent way to earn a living, so if that's your bag, then go for it! There are more opportunities cropping up every day.

The problem I ran into when consulting on SharePoint (and other choice products back then) was that although it was well paid, all I was doing was going onsite to fix more and more disastrously broken installations, rendered that way by their employees who lacked the necessary skills to tame the beast. “Great!” I thought at first, an opportunity to teach someone and coin it at the same time.

But it was slog work, it became a hair-pulling exercise in drudgery. Every time I turned up to fix another broken system or install a new widget, a small part of me died. I wasn’t growing or innovating, I was stagnating, but heck did I have a nice car! It feels a lot like how I see the Angular landscape panning out in the next 5 to 10 years.

Masquerading as JavaScript

Very often you’ll see a tutorial or hear someone say “Hey look, I wired up my Angular app, put in a few directives and it’s all working without writing a single line of code” … wait? What?! That sounds an awful lot like those Microsoft demos they do on stage at the big conferences showing off the flashy auto-code generating tools spouting the exact same line, all the while thinking that we’re impressed by this fact.

And that’s exactly how Angular started it seems – a tool for back end developers to build web apps – so the front end needed to be dumbed down so that folks didn’t have to write too much code there, or any if they could help it.

Anyone who has ever had to build anything of substance, knows all too well that scalable, stable, maintainable systems require code, and a lot of it. If it’s a back end complex system, it will require a lot of code. If it’s a front end complex system, it will require a lot of code. Anyone trying to convince you different is either lying, or is from the future and knows something we don’t today. And make no mistake, Single Page Applications, (the space Angular claims to play in) are all about building complex front end systems.

You're left with Angular experts who know very little about JavaScript

I’ve found that, the more you lean on a framework to dig you out of trouble and solve your problems for you, more and more it bends under the weight of that pressure … and there’s only so much any structure can take before it either starts falling apart slowly, or just outright collapses.

By focussing on pleasing the framework, and continuing to lean on it, particularly on its pressure points, you are investing specifically in that area. When you next look up and survey the team around you, you will realise that you’re left with Angular experts who know very little about JavaScript. If that’s your goal, then great! But let’s not pretend these developers will be any good at plain ol’ JavaScript when they graduate, or go looking for other jobs in the field.

Conclusion

So as you can see, it’s pretty unlikely I’ll be using Angular in any of my future projects unless v2.0 absolutely blows my socks off. I’ll more likely end up using Ampersand or maybe I’ll take the brand spanking new Aurelia for a spin!

That doesn't mean to say I won't ever be looking at Angular again, but they've lost my interest for now, and it's going to take a lot to get it back given the plethora of better choices out there today in the ecosystem.

Good luck choosing your framework! I just hope it’s not an Angular instance that I have the bad luck of supporting at some point in my future life…

Until next time,
Robert The Grey

Photo credit thanks to http://www.flickr.com/photos/yukop/7399778412/in/set-72157628494205581/



14 comments

Dom Barker
1/28/2015 6:09:49 AM
hey rob, can you elaborate on the bad habits that juniors are picking up? I'm curious!

Robert Greyling
1/29/2015 9:29:58 AM
Hey Dom, sorry about the delayed reply. I started responding and eventually realised I was composing an entire article :) So I did the logical thing and [created it here](/stories/3718)! Hope that answers your questions.

Dom Barker
1/28/2015 5:21:11 PM

Paul Wheeler
1/28/2015 8:14:15 PM
We're currently using Angular at work and luckily haven't run into any issues. That's probably because we're using it in a very simplistic way to render the views and all the important stuff happens behind the api on the server. I've read enough articles at this point that I'm almost just waiting to find myself in some sort of situation that I can't find an elegant way out of, but gladly it hasn't happened yet (we're up to about 30 screens or so on our current app). I've got to say that Aurelia looks like all the stuff we love from Angular without the needlessly complex nonsense, so I wouldn't be surprised if we start spiking with it at some point.

Robert Greyling
1/29/2015 9:45:49 AM
hey @paulwheeler - is you're lucky enough to be able to move onto something like Aurelia, I would definitely recommend it. Been spiking a few things out over the last few weeks and there's some seriously good stuff there. The packaging side still has a ways to go, but it's great for dev POCs at the moment

Braun Goodson ✞
4/8/2015 11:44:27 PM
I've literally never signed up in such a hurry to comment on such a bloated and undermining article. As I read this--with a haste of excitement that someone finally found a legitimate reason why angular should be avoided--I immediately began to suspect the writer was, "one of those .NET guys." Fortunately, my intuition was correct. The more I read the less I saw in terms of actual facts and examples that prove angular should be left in the dust. As a matter of fact, there really only are two pseudo-true statements, and one actually true statement, in the entire article: the first being that angular does pack everything javascript under its hood (which, well, duh, that's the point of a front-end framework), the second being that it's too loosely declarative in the sense that it's easy to use it incorrectly, and the third (the only real true statement) being about angular's two-way data-binding performance (which can easily be resolved with react virtual dom). But, we're adults here. So, let's act like it. Anyways, in the end, I'm laughing, because .net is what should be avoided, not angular.

Aidan Gee
4/10/2015 9:35:14 AM
Hey Robert , I use Angular a lot in my job and personal projects and although some of your post sounds very anti-angular I do think you make some great points. I've been a developer professionally for around 3 years now and been using angular for about 2, so have immediate experience about how it can obfuscate your view on javascript as a junior. It's quite easy to pick up angular as a junior and follow the documentation to create great apps with essentially little knowledge of whats actually going on... it just works. This is fine until the next new javascript framework comes along and your essentially starting again because you don't have that core knowledge. Not sure I agree with your pretty gruesome analogy of "like a cancer in your views" though. Maybe its because i've just become accustomed to it over the years but I think angular gives you some good ways of keeping your HTML looking like HTML. Good post , made me think. Ultimately, theres so many javascript frameworks now is there really a right / best choice?

Robert Greyling
4/10/2015 1:31:02 PM
Thanks for your thoughts @Aidygee - it really helps to hear from devs who are fairly new to Angular and JS at the same time - I sometimes forget. For me I jumped for joy when Angular came out, but I had been writing JavaScript since 1996, I've been through some pretty interesting times and already had a decent foundation of knowledge in place before ever picking up Angular. I loved how easily and quickly you could get up and running and build something useful - it was quite literally the silver bullet I'd been looking for when it came to apps on the web. I was very careful (just like you) to keep my views tidy, but only because I had past experience of the pitfalls and I was aware of just how ugly they can get as I'm sure you've seen in your two years of using it. My analogy of "cancer" came about because just as a patient doesn't necessarily notice the signs of cancer and it can progress pretty far before it's caught, so too did I see this same thing happening with my junior developers. The number of code reviews I sat through, painstakingly explaining what was wrong, and why, and how to do it better was for me a massive time sink, and I think this article (and the follow up one specifically about juniors) was the result of the final straw that broke the camels back. The choosing of my title for this was very deliberate as you can imagine. The last part might seem quite sensationalistic (...and neither should you) - and I can see that now, but at the time my thoughts were: _this is my advice to you developer - don't use it_. And the inclusion of the the words "next project" was also very deliberate for many reasons which I highlight in the article. Angular 1 in my view is too painful to introduce to new developers, and Angular 2 is close enough to release yet and changes a bunch of stuff, so we're stuck on the Angular front, can't use v2 yet and don't want to use v1. Does that make sense? I don't want to throw away the Angular knowledge I've built up over the last few years, nobody does, so of course I'll be taking Angular 2 for a spin and see how it holds up against some of the new players in this space. You ask a question as to what is the right choice, well far be it from me to dictate, but since you asked, here is my opinion as of now: For me React is doing some very interesting things in this space, and is worth checking out, but as many will tell you, it's not a framework, it's really just a rendering engine when you boil it down, but it's a good one at that. From there you need to introduce something like a Flux framework, Router etc to build some real apps with it, but that does kinda make it modular enough to give you the freedom to choose - sometimes that freedom makes it harder though. Secondly, you've got Backbone, and what I like to think of as the spiritual successor Ampersand which takes the best of Backbone and has achieved a truly modular solution which I really like the look of. I've built some POC stuff with it and so far it really shines. Lastly, and this would be my current personal favourite, is the Aurelia framework for a number of reasons, and I'll be writing another article here in the next few days which will include a full breakdown of why. But the key factors that attract me are: I'm writing ES6 today, the getting started story is nothing short of braindead simple, the docs are good, it's incredibly modular - I could render with React if I want - and the community around it is unbelievable when you consider it doesn't have a Google or a Facebook to push it yet. Anyway - thanks for stopping by - great to get some feedback :)

John
5/28/2015 5:04:23 PM
I'm surprised you made no mention of Karma or Protractor and the TDD foundation behind Angular development. Closely integrating unit and E2E tests into the daily development process is a huge component to Angular, not well matched by any of the other client-side frameworks. I think that's a big part of why it's so attractive. I'm also quite happy that Angular 2.0 is a long ways off. I don't agree with the structural changes that have been proposed and I will likely stick with Angular 1.x even after 2.0 is released and stable, at least until I have a working grasp of ES 6.

Robert Greyling
5/28/2015 5:08:26 PM
@real_currents Hey John, thanks for the comment - glad you like the site :) Good to have you back! I've used Karma, Jasmine, Protractor etc. in any number of combinations across many projects built in Backbone, Angular, Durandal, Ember, Aurelia, Mithril - you name it. It's definitely not unique to Angular :)

Guillaume Balaine
6/7/2015 8:01:26 PM
@RobertTheGrey So you've been using an E2E testing library and tool created by the Angular team which you rant don't design their framework for testing. Okay.

Robert Greyling
6/7/2015 8:23:49 PM
@Igosuki If you're using Protractor to test logic that should be in your controllers, but has actually leaked into your views, then that's part of the problem I mentioned above because I believe it makes apps hard to debug. Unfortunately, it's one of the traps that many people fall into when building with Angular. At no point did I say (or rant) that Angular wasn't designed for testing - it's JavaScript, of course it can be tested. But there are such things as brittle tests. Those often come from relying on E2E for logic (or unit) tests instead of simulating pathways through the software which is its primary focus. Embedding logic in your views is a first class ticket to that world of pain. Let's also make one thing clear - the "Angular Team" that built Angular back in 2009 is significantly different than the team who built Protractor in 2013 - even if it's some of the same people, they will haven't learned a lot in 4 years. And the proof of that is evident in the way Angular 2 is designed - it's very different to v1 with many of the learnings applied.

John
5/28/2015 5:05:10 PM
P.S. JSK is looking great. Glad to see some original articles here :)

Thomas Roch
7/17/2015 5:15:20 PM
I don't think Angular is that broken, but it is a complex tool (too complex) that you can't put in everyone hands. The learning curve is long and it takes time to settle (that's true for a lot of frameworks). From experience leading a team on a greenfield project: not everyone gets it, and things can spiral quickly out of control (I used to live coming back from a two weeks holiday). However, there are some good bits with angular: use of promises, factories, code reusability, dependency infection... A lot of skills acquired with angular are transferable. Its main issues are ignorant watchers, app wide digest cycles and directives are non composable. I totally agree with your parallel with SharePoint. I consulted for 6 months on angular based applications on a horror codebase, mostly written by designers and .net devs, and people had had such a bad time on it that none wanted to question their own codebase and skills. But i don't know whose fault it is: an industry moving to quickly creating its own skills draught, angular marketing itself as super heroic or being too popular (so devs are not trained enough or don't realise it). A bit of everything I think. And oh, the angular community is also responsible for spreading misuse with bad boilerplate code. Google too with angular material. I don't want to finish on a too negative note, there are great things with angular and it is possible to create very good apps. I always feel it provides a good skeleton, the view lets it down.

Robert Greyling
7/22/2015 10:29:46 PM
Thanks @tcroch for the insights. Who knows what will happen with ng2.0 in the next few months, but we will see. I do hope the community don't end up spreading the misuse once again and that the team are very clear with best practice guidance. I think the lack of that strong guidance is a big part of the reason Angular has become so hard to find good examples/docs for.