State of play

How you ended up using AngularJS.

Let’s just get this out of the way. All developers believe they know JavaScript. Like strings in Java, this fact is immutable and is referred to hereinafter as simply “the Fact”.

Every enterprise web project started in 2014

Your team has been chosen to redevelop the company’s flagship web-based product as a SPA. Necessarily this will involve a great deal of JavaScript, of which — without jQuery — no-one in the team has written more than ten concomitant lines before.

At this point you stick up your paw and ask when the training course starts. Or at the very least you enquire how many weeks worth of consultancy have been booked with an expert to help the team get up to speed with the language. In theory.

In reality, one of two things occurs.

Typically, the team silently and directly succumb to the Fact. Occasionally however, in an apparent outbreak of common sense, the team has an honest discussion amongst themselves, discovers that no-one in the team has any meaningful experience with JavaScript and agrees that this poses a serious risk.

But here’s the rub. In this latter scenario the Fact still holds (remember: immutable); every team member still secretly believes they already know JavaScript. Publicly however, to maintain congruence, they decide to use a cross-compiler with CoffeeScript or TypeScript (because ‘1' == true, WTF?).

Unfortunately, however, this merely reduces down to the same problem. But with a slightly less helpful ecosystem and a more complicated debugging story.

A leap of faith

The human mind has a cool feature called cognitive dissonance. A bit like the cat in the box in quantum theory, this means that whilst a developer will believe they know JavaScript, at the same time they will also be aware that they really don’t.

Enter AngularJS.

The reasoning goes thus. Even though I fully understand JavaScript, I still kind-of-don't and so I might make a mess of it. A framework will provide me with some “rails” and prevent me from going too far wrong. AngularJS is backed by Google and they know what they're doing so let’s use that.

And now, just like the adage about regular expressions, you have two problems. Or more accurately: two technologies you don’t understand. And to add insult to injury, AngularJS is unlikely to help you in the long run if you ever do get upto speed with the new language.

Where do you see yourself in five years?

Ordinarily, I wouldn't care about all this, but I can see history repeating itself here and last time around it was somewhat soul destroying for all involved.

I remember for example, in the early years of my web development career asking a question on a forum. I asked how, using ASP.NET WebForms, I could perform an action in response to a button press inside a pop-up on a Google Map instance.

In the ASP.NET WebForms world this was very advanced stuff because the abstractions at hand (e.g. WebControls) simply did not envisage such a scenario. It could be done, but you would have to introduce your own abstraction based on the existing WebForms abstractions and then go from there.

Of course using plain old event binding and manipulation of the DOM, solving this problem was trivial — but I had the wrong cognitive abstractions at hand and so I was left adrift.

If the next few years pan out as I think they might, a generation of developers will grow up thinking in terms of directives and scopes and have similar problems. Companies will continue presenting ever more technically challenging requirements, oblivious that in so doing they are asking developers to push framework abstractions past breaking point.

And so the merry-go-round will turn. Seasoned developers will roll their eyes and subvert the abstractions to just get the job done. Bright-eyed developers will submit pull requests to AngularJS.

Unless… unless we take a lesson from history, make a break with the past and learn to use Web technologies directly. I don't believe this will happen, but for the sanity of my future self, I sincerely hope it does.