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.
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.
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.
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.
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/