>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>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.<p>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:<p>>In Angular, a Controller is a JavaScript constructor function that is used to augment the Angular Scope.<p>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.
(sorry if this comes off a bit snarky)<p>"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"<p>Blindly overusing most features in frameworks or libraries can cause performance problems. Which memory leaks?<p>"Writing Controllers and Directives that take dependencies which make them nearly impossible to test."<p>Doesn't dependencies in general make any code harder to test?<p>"Views that are heavily dosed with logic - but more on that later"<p>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?<p>"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."<p>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.<p>"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"<p>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.<p>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.
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.
There was a lot of commentary on my first post <a href="https://javascriptkicks.com/stories/2657" rel="nofollow">https://javascriptkicks.com/stories/2657</a> about not detailing enough why I think Angular isn't good for junior programmers asking for more detail. Here it is.<p>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.<p>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.<p>I hope my next post will be a lot more cheerful :)
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.
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.<p>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?
>those that said I was just spouting FUD<p>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.<p>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.<p>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.<p>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.
I am not a web developer but I have been trying to keep up with the technology.<p>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.<p>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.<p>It kind of brought back memories of first generations of Enterprise Java frameworks (you know the factoryfactorymanager joke...)<p>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.<p>Anyway, if you care for another data point, there it is.
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.<p>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.
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.
> 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.<p>I have come to learn that the majority of people who <i>say</i> they work in a particular system have actually only ever dabbled in it.
MVVM has been around for years and years. It's just newish to the JS scene.<p>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.
If anybody is having issues loading the page, here's a really long screenshot of the text... <a href="http://milankragujevic.com/uploads/2015-01-29_151409.jpg" rel="nofollow">http://milankragujevic.com/uploads/2015-01-29_151409.jpg</a>
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.