larlet-fr-david-cache/cache/d93c608753d1c55ee135eebed5ba7477/index.md

title: Why junior developers are learning bad habits from Angular
url: https://javascriptkicks.com/stories/3718
hash_url: d93c608753d1c55ee135eebed5ba7477


TLDR;

 * This is for folks who want some examples backing up my statements from my last post
 * Basically, juniors fall into patterns of behavior early on, and it's hard to shake them out of it
 * Angular **requires** some workarounds depending on what you're optimizing for which can quickly become anti-patterns in the hands of junior developers

<p>When I wrote the other day about the fact that <a href="https://javascriptkicks.com/stories/2657">I won't be using Angular in my next project</a>, one of the key points I raised was that junior developers are learning some bad habits when working with Angular. Quite a few people agreed with me - primarily because they had experienced it themselves, and that was the end of the discussion.</p>
<p>But on the other hand there were two more camps I noticed; the first being developers who may not have worked on Angular and genuinely want to know why I made those statements, and the second camp, <a href="https://news.ycombinator.com/item?id=8953366">those that said</a> I was just spouting <a href="http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt">FUD</a> because I didn't explain myself in detail, which surprised me a bit because those are developers who presumably have been working on Angular and in my opinion should already know about the pitfalls and their effect on juniors. And if they don't already know, then I thought I had linked to enough other (much better) articles explaining those pitfalls.</p>
<p>So either the second camp is somehow blinded and does not want to see, or they're just lazy and didn't bother reading through the linked posts. Given the links, I wasn't particularly worried about explaining myself to the nth degree, plus the fact that my article was already edging up to 2.5K words and would probably lose even more readers if it was any longer. Either way, they're probably not the ones reading here now...</p>
<blockquote>
<p>This post is for those who genuinely want to know, but haven't pieced it together for themselves yet.</p>
</blockquote>
<h2>OK, so why single out junior developers</h2>
<p>Well, firstly, it's because they're obviously the most likely to fall into the traps - but secondly, and most importantly, they don't know right from wrong yet. It's like telling a child not to cross the road without holding an adult's hand. They don't know about cars early on, and hopefully they'll never find out first hand just how destructive they can be. I would like to protect my junior developers in a similar fashion, and Angular isn't helping, but I'll explain why.</p>
<blockquote>
<p>&quot;Traps?!&quot; I hear you say...</p>
</blockquote>
<p>I specifically mentioned &quot;bad habits&quot;, and I chose the term carefully, because habits are typically things you tend to learn early on in a practice, and once they're bedded in, it takes extra-ordinary effort to shake off. Senior developers in my experience tend to have been burned through this cycle once or twice already, and so are more likely to be open to better solutions when they see things just aren't right. Juniors... not so much - they just power on through hoping for a safety net.</p>
<p>For my first example, I'll use <code>$scope</code> as ~~my whipping boy~~ a way to establish a precedent for the differences between senior and junior developers. Consider the following fictitious Angular Controller;</p>
<pre><code class="language-javascript">(function () {
    var app = angular.module('jsk', []);

    function JskController($scope) {

        $scope.anonymous = function () {
            var user = !!$scope.username; //Noooooooo!!!
            return !user || $scope.username.length === 0;
        };

        $scope.displayName = function () {
            if ($scope.anonymous()) {
                return;
            }
            return $scope.name;
        };
    }
    app.controller('jskCtrl', JskController);
})();

</code></pre>
<p>The <code>Controller</code> is just a wrapper for <code>$scope</code>....why? What's the point in even having it if it's just a proxy? It's <em>supposed</em> to represent the view-model at the very least. This is also typical of developers who do not approach a problem with testing in mind, and have no issue passing <code>$scope</code> around thereby coupling the <code>Controller</code> to the data-binding, and forcing a ton of unnecessary mocking if they even bother to write unit tests in the first place.</p>
<p>Many would not even see the problem here, and just as children don't know cars can hurt, juniors don't know just how destructive this anti-pattern can be to performance, separation of concerns and long term code base maintenance.</p>
<blockquote>
<p><em>This simple little anti-pattern will now pepper your code throughout if not rooted out</em></p>
</blockquote>
<p>And now that the junior developer has done this once, they will do what every junior developer does exceedingly well - they will Copy+Paste their way into oblivion. This simple little anti-pattern will now pepper your code throughout if not rooted out, and <em>that</em> requires an experienced head that knows enough to spot it and provide a better way. Rinse and repeat.</p>
<h2>Polluting other frameworks</h2>
<p>Now take that same junior developer and move them onto another project that just happens to be written with another framework, let's pick <a href="http://durandaljs.com/">Durandal</a> for example. There's significantly more JavaScript™ and a heck of a lot less framework stuff that you touch daily. The same can be said for frameworks like <a href="http://backbonejs.org/">Backbone</a> and <a href="http://ampersandjs.com/">Ampersand</a>. You're basically working with pure code mostly, and using the framework around the periphery where it stays out the way, but where it can be a useful time-saver.</p>
<p>In the hands of a junior fresh out of the Angular project, all of a sudden you see application state get pulled in and passed around <em>just</em> like it was done with Angular. When confronted, they just shrug and say &quot;that's how I did it on that other project&quot; - and so starts the cycle of corrective instruction. The juniors who have never touched Angular, so far in my experience don't tend to exhibit these tendencies straight off the bat. They tend to learn from patterns being used in the code base they're working on and from the most recent, and it took me a long while to see it.</p>
<h2>Other habits juniors learn from Angular</h2>
<p>I'm not going to give an example for each - that was the point of my ~~whipping boy~~ example above. Suffice it to say that this post is long enough already, and that there most certainly is an example you'll be able to find if you Google for it.</p>
<p>Off the top of my head, the list of things juniors do includes, but is not limited to:</p>
<ul>
<li>Overuse of the eventing system (<code>$watch</code>, <code>$emit</code>, <code>$broadcast</code>) leading to performance problems and memory leaks and not realizing it or being able to debug it</li>
<li>Writing <code>Controllers</code> and <code>Directives</code> that take dependencies which make them nearly impossible to test.</li>
<li>Views that are heavily dosed with logic - but more on that later</li>
<li>Their first experience of DI is quite often that in Angular and it's horribly broken. Since the &quot;patch&quot; which fixed the minification issues, it's still really just a square peg in a round hole with woeful support for scope and lifetime and features which most DI gives you for free such as child containers. They end up hating DI and shy away from it on other projects.</li>
<li>Strange bugs that (when called over) have us all scratching our heads until one of use realizes - oh yeah, sorry we forgot to mention that pretty much everything passed around is global, and <code>Directives</code> etc. aren't namespaced, so I see what's happened - you've got a naming collision there</li>
<li>It's getting late, but I hope you get the idea...</li>
</ul>
<h2>Hacks and other debauchery</h2>
<p>Data-binding is broken. Some changes to Angular under the covers have made it in because of this, but having to go back and be explicit about which things should be one-way versus two-way is a big job, especially on large invested code bases with very few tests.</p>
<p>What's that got to do with juniors? Well, they possibly did a lot of the data-binding work up front, and will continue to do so as the app is maintained. Can you trust them to use their judgment as to which type of binding to leverage? Do you even know yourself? Are you sure?</p>
<p>I already explained why I dislike the view templating system, but I mostly dislike it because of what juniors do with it. Apart from being horribly inefficient with the DOM, terribly difficult to read or give out to design agencies, when you leave the juniors alone with them long enough, you'll find that they are exceptionally good at shoving <em>all sorts</em> of logic and programming in there. Maybe not something that would cross the mind of a senior developer straight away, but when you see it, you literally catch yourself saying... &quot;wait...What?!&quot;</p>
<p>You have to go through every commit with a fine toothcomb and rap them on the knuckles each time they do it. But there are so many ways in which they can make this mistake, (because they find all their damn examples on the bloody internet in blog posts like this one) which means that <em>they</em> end up with very red knuckles and <em>I</em> have all my hair torn out. That's the point where I start asking if it is worth it or not. And the answer is no, no it most certainly is not.</p>
<h2>Conclusion</h2>
<p>I know that a lot of the things I've mentioned above can be attributed to a simple fact that juniors make mistakes, and require guidance to get better, but I've been in this game for over 20 years now, and at no point in my career - apart from possibly working with SharePoint ;-) - have I struggled as much to get the juniors to &quot;step away from the keyboard&quot; and <em>think</em> about the crap they're writing.</p>
<p>I hope that this post has gone some way towards helping you understand why I personally want to keep junior developers away from Angular. I hope it hasn't come across as pure <a href="http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt">FUD</a>, and rather measured opinion, but by all means, I'm happy to stand corrected if you feel there is a better way, so feel free to leave your comments and we can have a discussion about it!</p>
<p>Until next time,
<a href="https://twitter.com/robertthegrey">RobertTheGrey</a></p>