
Why junior developers are learning bad habits from Angular - senoff
https://javascriptkicks.com/stories/3718
======
jere
>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.

Yup, I don't get it. I guess not only am I eternally doomed to be a junior dev
but also am being compared to a child, a monkey typing at a typewriter, but
also someone who doesn't know JS at all. Feels good man.

Other than some horribly obtuse undefined checking, there's no explanation of
what the problem is. The argument seems to be that the controller depends on
$scope. I... I thought that was the point. From the first line of
documentation on controllers:

>In Angular, a Controller is a JavaScript constructor function that is used to
augment the Angular Scope.

If the idea is that this is a bad habit to bring elsewhere, fine. Some more
explanation would be nice, but whatever. But the implication is that this is a
trap within the context of Angular dev itself.

~~~
delluminatus
The thing that struck me about it was that the $scope.displayName() function
shadows itself by setting $scope.displayName again:

    
    
            $scope.displayName = function () {
                if ($scope.anonymous()) {
                    return;
                }
                $scope.displayName = $scope.name;
            };
    

I have no idea how that's related to Angular, though. It looks like it's just
bad programming practice.

~~~
dmak
I agree completely. You wouldn't do this any ANY language let alone Angular.
However, I get he is trying to make a point that junior developers are using
the $scope too trivially therefore causing slow performances, but this can be
easily overcome by just incorporating better conventions into your codebase.

------
yummybear
(sorry if this comes off a bit snarky)

"Overuse of the eventing system ($watch, $emit, $broadcast) leading to
performance problems and memory leaks and not realizing it or being able to
debug it"

Blindly overusing most features in frameworks or libraries can cause
performance problems. Which memory leaks?

"Writing Controllers and Directives that take dependencies which make them
nearly impossible to test."

Doesn't dependencies in general make any code harder to test?

"Views that are heavily dosed with logic - but more on that later"

I certainly don't feel my views are dosed with logic? Which kind of 'logic'
are you referring to here? Is there something preventing you from moving your
logic outside of the view?

"Their first experience of DI is quite often that in Angular and it's horribly
broken. Since the "patch" 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."

This seems like wild speculation here, as well as not being very specific (how
is it broken?). I'm sure DI in Angular could have been done in a more elegant
way (I have no idea how), but I don't seem to run into any problems.

"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 Directives etc. aren't namespaced, so
I see what's happened - you've got a naming collision there"

Not sure what to respond here - you had a bug in your code and discovered it
was due to naming collision. Do you run into this daily? I've run into
'strange bugs' or at least hard-to-diagnose bugs in almost every framework or
library I've used.

None of these issues seem especially unique to Angular. I'm not saying Angular
is a perfect framework, but my own experience have been mostly pleasant, and I
don't feel that there is anything in particular in Angular vs. other
frameworks or libraries that encourage bad behavior - juniors or seniors.

~~~
eyko
"Blindly overusing most features in frameworks or libraries can cause
performance problems. Which memory leaks?"

Binding to event emitted by an object on another object, then deleting the
receiver, can cause a memory leak if you don't unbind first.

~~~
rubicon33
iOS has the exact same situation for it's notifications framework
(essentially, observer pattern).

From what I've seen, consistently across frameworks that support the pattern,
that you need to de-register your listener before releasing it from memory.

Pretty funny to think, I'm a "junior" developer and even I know that you have
great power, but also responsibility, in the observer pattern.

------
colund
The page is not loading properly for me (on a Windows laptop with Chrome).
When I use the given link I get "500 - InternalServerError Something went
horribly, horribly wrong while servicing your request. We're sorry :-(" and
when I go via javascriptkicks.com it keeps loading and never completes.

~~~
ceeK
I somewhat assumed that the 500 error was evidence of the post's title, heh.

~~~
sfjailbird
Seriously. Why do you need to run a shitload of JavaScript just to display a
damn article.

~~~
ExpiredLink
Bad habits. Those JavaScript kids nowadays ...

------
robertthegrey
There was a lot of commentary on my first post
[https://javascriptkicks.com/stories/2657](https://javascriptkicks.com/stories/2657)
about not detailing enough why I think Angular isn't good for junior
programmers asking for more detail. Here it is.

One of the big motivators for this follow-up post is due the the cries of FUD.
Of course it's just my opinion, but I like to back my opinion up with facts if
possible and it seems there were some questions cropping up around how much of
a problem it geniunly is versus me just having a whine about it.

In all fairness I'm excited about Angular 2.0, but it's just too far off to
quantify its use just yet. So it's not that I'm anti-Angular, I'm just anti-
Crap, and there is a lot of that in the first incarnation I'm afraid, and it's
biting too hard to ignore.

I hope my next post will be a lot more cheerful :)

------
city41
I find it interesting that most negative Angular articles are so vague. Why is
it so tough to articulate what is wrong with Angular? I agree Angular is not
the best, but I don't have such strong negative feelings for it. I've used it
successfully in the past and as long as you keep things simple and don't go
overboard with all that it offers, you can create a decent website with it.

------
davexunit
I wish I could go back in time and strongly oppose AngularJS at the last place
I worked. Knowing what I know now, it was such a bad idea. I also made the
mistake of adding it to a resume, too, so I have gotten too many recruiter
emails about AngularJS jobs.

AngularJS has an amazing success/failure story. The developers have managed to
get their technology used by so many web development teams whilst being
extremely over-engineered and having a very steep learning curve. Why did so
many of us get enamored with it in the first place? The power of Google?

~~~
woah
The overengineering actually led to success, as it resulted in a batch of non-
JS devs thinking that they had discovered some secret magic. They went on to
write a bunch of blog posts, which made people think it was good.

~~~
fixermark
Enabling non-JS devs to create a rich experience website (even if it has
performance and future-proofing flexibility issues) _is_ secret magic. Never
underestimate the number of non-web engineers who desperately want to make
browser-accessible frontends to their tools without having to learn the "hell"
that is Javscript.

I strongly suspect people were writing those blog posts because Angular worked
for them in a way that alternatives had not; I hear that's how things get
popular sometimes.

------
batoure
>those that said I was just spouting FUD

I was not part of the crowd that made this comment at the outset of the first
article but I would say that the second article only confirms the suspicions
of these readers.

Identifying a treacherous design pattern is one thing. To say that a
particular pattern says one thing or another about the skill or scale of a
particular developer is another. Especially in the land of Javascript
frameworks where the flexibility to do and incorporate anything can be a
serious poison pill.

I have worked on and lead two teams that implemented angular projects, on the
first we moved into it as a group of relatively experienced developers. In the
second we on-boarded a number of junior developers. My experience with the
junior developers was that they took their queues pretty quickly from the work
of the senior developers.

In particular I have never seen this particular pattern in our code. I have
found that the tendency to want to break the angular paradigm with outside
JavaScript or angular library injection overkill are much more common
practices that we end up needing to spend time quashing.

------
rdtsc
I am not a web developer but I have been trying to keep up with the
technology.

I tried learning Angular because people at work started using and hyping it
beyond measure. So I thought 'ok' this got to be really good stuff.

And it was good, _if_ experienced people held my hand. Otherwise I got lost in
a soup of what seemed like unnecessary terminology -- $scopes, controllers,
digest cycles, dependency injections, directives, and so on.

It kind of brought back memories of first generations of Enterprise Java
frameworks (you know the factoryfactorymanager joke...)

So I have seen Angular work easily for already experienced devs who knew web
front-end development very well. For me, what I really like is React. Ever
since watching Peter Hunt's video one or two years ago, the idea of the
virtual DOM and how events propagate made sense and was small enough to fit in
my brain. I was able to go through some tutorial and do a few toy project in
my spare time.

Anyway, if you care for another data point, there it is.

~~~
fixermark
Unfortunately, that issue isn't limited to angular: it falls under the general
category of "If you haven't gotten burned by the problems a pattern is trying
to solve, a pattern looks like unnecessary complexity." I'm reminded of when I
had to learn COM back in the day; as a developer who had cut their teeth on
programming on Macintosh followed by Debian, it seemed like needless
complexity until I grasped the zen of the problem it tried to solve: providing
a common protocol for different binaries _compiled by different C++ compilers_
to share data structures and do inter-process communication in an object-
oriented fashion _without sharing source code._ COM seemed way too complex to
me because (a) in the Mac world, there was only one compiler that mattered (at
least by the time I got into it), so binary incompatibility was essentially a
non-issue, and (b) in the Linux world, if you needed two modules to inter-
operate, you could meld their source code together.

Similarly, if you haven't tried for 100% test coverage, dependency injection
seems needlessly complicated, and if you haven't had to nest dozens of HTML
templates written by different developers using different patterns, directives
seem way over-engineered.

~~~
ep103
I strongly disagree. The idea of a directive isn't unnecessarily complex
because it isn't needed. And yes, there should be a pattern to force their
use, for exactly the reasons you specified.

The claim that's being lobbied against Angular, however, is that they were
schizophrenic in their choice of implementations for all of their patterns, or
to state it another way, that the same advantages could have been gained with
much, much simpler patterns. Instead of building a nice clean framework, they
built an auto-magical framework, and declared you must learn every workaround
in the "Angular Way" to use it.

There are plenty of js frameworks now, many of which have analogous components
to directives and controllers and views, etc. But while most, if not all of
them, allow for the same advantages you've mentioned, few of them do so in
such a complicated, boilerplate, and arbitrary manner.

And this is scary, because it looks like they're continuing this trend with a
completely new "Angular 2.0 Way".

I'm going to go off the deep end here for a moment, but, back when I was in
college, I took some marketing class where they discussed in depth the idea of
user interface as a method of product lockin. The idea was if you built a
product simple enough, but then obfuscated the correct method of usage
correctly, you could make a product that was simple enough that new comers
would be drawn to your product, but complicated enough that it would take so
much time to master, that most who did so would actively desire never to leave
as they were now the local experts. SharePoint really is a poster-child for
this sort of dark design. And I think of this every single time I use angular,
not because the ideas are wrong, but because of what simple things were
implemented in a complicated manner, and what others were made auto-magical.

~~~
fixermark
To pull it back a bit from the deep end: another possibility besides
intentional vendor lock-in is that AngularJs dates back to an initial public
launch of 2009 (and was likely older than that in the bowels of Google's
infrastructure), while the frameworks that have been mentioned in this thread
are younger (react: 2013, boostrap: 2011). It's quite possible that angular is
simply over-engineered to solve the problems it's targeted to solve and other,
younger frameworks have second-mover advantage on architecture and design
(while angular has first-mover advantages of "Older, therefore more well-
understood" and "wide adoption base").

COM wasn't the last word on binary cross-communication either; for various
reasons I see that sort of thing done a lot more often these days via building
a RESTful HTTP service, even when the intent is localhost-only communication.

------
istorical
It seems like what junior Angular devs really need is a post showing examples
of both what NOT to do and also what to do INSTEAD.

I think the difficulty of Angular is largely you have so many tools available
but it's hard for a junior developer (like myself) to recognise when each
should be used.

~~~
thecolorblue
I agree, and this article does not really help. I feel that part of calling
yourself a senior developer is teaching junior developers how to write great
software.

~~~
robertthegrey
As I said in the post, you just need to google for it. Here's one I found that
helps you with $scope: [http://csharperimage.jeremylikness.com/2014/11/the-
top-5-mis...](http://csharperimage.jeremylikness.com/2014/11/the-
top-5-mistakes-angularjs-developers.html)

------
cpursley
In other news "How junior developer was able to quickly ship their first SPA
using Angular, satisfy client requirements and get paid."

------
guiomie
Anyone has an exemple on how to use the $scope properly ...? He only shows the
wrong way of using it, but has no code for the right way.

~~~
colund
Yeah I personally think the page has shown bad habits much worse than Angular.
I think AngularJS makes it REALLY easy to make SPA applications with data
binding. I find it ironic that they bash AngularJS while their own site has
(had) sever loading issues.

Don't blame the tool blame the fool :).

------
staticelf
Interesting, the title tells something about bad habits but as soon as I try
to visit it I just get a "loading" message that never seems to complete. If
something is a bad habit, that's how it looks like.

------
radicalbyte
Is there a way to open this full-screen? I find the pop very distracting.

~~~
robertthegrey
yes I'm working on that this weekend - also in an effort to fix the mobile
issues. Full posts will display on the page on their own instead of the side
bar like link stories appear

------
moron4hire
> the second camp, those that said I was just spouting FUD 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.

I have come to learn that the majority of people who _say_ they work in a
particular system have actually only ever dabbled in it.

------
MrDosu
MVVM has been around for years and years. It's just newish to the JS scene.

It is painful to read articles like this where even the author misunderstands
the pattern and failed to read some of the standard literature on the topic.
Just because MVVM is hip now does not mean everyone needs to reinvent wheels.

------
milankragujevic
If anybody is having issues loading the page, here's a really long screenshot
of the text...
[http://milankragujevic.com/uploads/2015-01-29_151409.jpg](http://milankragujevic.com/uploads/2015-01-29_151409.jpg)

~~~
Matheo05
Sorry but I got an "Error 1011, access denied"

~~~
milankragujevic
Fixed it. Probably.

------
wnevets
Why junior developers are learning bad habits from <insert anything here>.

------
yoanizer
I see a lot of hate, but I can't see the arguments.

------
robertthegrey
Apologies to those of you who might be having trouble viewing this on mobile -
it's high up on the list to fix in the coming days

~~~
warfangle
So... Are they learning bad habits like serving 500 errors to mobile devices?
;)

~~~
jasonwocky
Hah! Shows what you know. I've got a 500 on my laptop, too ;)

~~~
300bps
Yeah doesn't load on my Lumia 928 either. I bet OP is sorry he is missing out
on the traffic from the 2.6% of mobile users that use Windows Phone.

------
cheshire137
I wish he had clarified what was wrong with stuff. This article wasn't helpful
for me at all.

------
alblue
The blog rambles and disables native scrolling. It's not worth your time
reading it.

------
treerunner
Hmm. I think I'll check out what my boss blogged about today..

------
mcmillion
It's like Kinja, but somehow worse.

------
v512
seriously, the website design sucks.

~~~
MiddleEndian
Agreed. If you click out of the weird popup the article is in, you get a list
of articles. If you click on one of those articles, a new window/tab opens in
your browser, with a similar setup (article in weird popup), and if you click
to the left of that, now you have two windows/tabs with lists of articles.

I almost wonder if it was made like that as a joke.

------
kuni-toko-tachi
The central problem with Angular is what is says about the software industry
in general - that a framework so fundamentally and ridiculously flawed could
invite such wide appeal suggests that many people have absolutely no idea what
they are doing. The thousand monkeys approach to engineering has wide
implications for security and safety of systems that we rely on. There is
simply no way that you can say that you know Javascript and at the same time
support Angular. None.

~~~
kyberias
This is a rather surprisingly and unnecessary harsh comment. Would you like to
explain why do you think Angular is so flawed?

~~~
JanezStupar
For one, it is incompatible with the whole open web stack. You cannot use
Bootstrap with it. And if you decide to move off Angular, you are going to be
in a world of pain.

Second and worst of all - it is a monolithic framework. As long as you just do
things the "Angular Way" \- you are fine. If you want to change or override
something, you are in a world of pain.

If you are learning Angular - you are hardly learning JavaScript. The
knowledge learned from it is hardly transferable to the next framework down
the line.

To me it looks a lot like SOAP. Everybody is acting like they understand what
is going on. But nobody really does.

~~~
amsheehan
1: You shouldn't be using bootstrap, even though you can with angular.

2: What do you need to do in the front end that can't be accomplished the
'angular way'? I'm not sure you understand what monolithic really means. The
beauty part of angular is that you can use it as little or as much as you'd
like in your web applications.

3: Angular 2 is going to be preeeetty much only ecma6. Also, understanding
angular means you understand AMD, digest cycles, etc... totally applicable to
other frameworks.

4: What are you even talking about?

~~~
jtreminio
> 1: You shouldn't be using bootstrap, even though you can with angular.

Why in the world would you say that

------
lcfcjs
Fix the site! this sounds interesting

~~~
simlevesque
The mobile site it is totally broken

