Why junior developers are learning bad habits from Angular • Hacker News Board

Re: Why junior developers are learning bad habits from Angular

#131

Post by magikid » Thu, Jan 29, 2015, 5:31 PM UTC

tericho wrote: post #100

mcv wrote: post #79

Earlier quoted context omitted.

Well, there's a good reason why $scope and controllers will disappear with Angular 2.0. $scope is convenient, but also a massive source of problems. There's workarounds for those problems, but those workarounds wouldn't even be necessary if this aspect of Angular had been designed better. Angular has some great stuff, and some really necessary ideas and principles that were sorely needed in Javascript. I love working…

This is anecdotal, but I once found this incredible use of $scope while viewing the source for a sports page: https://gist.github.com/tcrosen/96279e39f9b0fb85c266

I just started learning Angular and that code smells. Why wouldn't you make some sort of object for all of those and assign the object to scope?

Re: Why junior developers are learning bad habits from Angular

#132

Post by batoure » Thu, Jan 29, 2015, 5:35 PM UTC

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

Re: Why junior developers are learning bad habits from Angular

#133

Post by alblue » Thu, Jan 29, 2015, 7:17 PM UTC

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

Re: Why junior developers are learning bad habits from Angular

#134

Post by angersock » Thu, Jan 29, 2015, 7:32 PM UTC

xyzzy123 wrote: post #38

kuni-toko-tachi wrote: post #9

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 kno…

Angular brutally sucks in a variety of ways, but security isn't one of them [pentester]. Specifically, the builtin "stuff" makes it actively hard to XSS, and in SPAs that's job #1.

So, all all seriousness, what is the actual danger of XSS? Where does that typically come in?

Is it an issue on an intranet app with a controlled stack?

Re: Why junior developers are learning bad habits from Angular

#135

Post by rubicon33 » Thu, Jan 29, 2015, 8:43 PM UTC

eyko wrote: post #58

yummybear wrote: post #14

(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 de…

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

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.

Re: Why junior developers are learning bad habits from Angular

#136

Post by bmm6o » Thu, Jan 29, 2015, 9:04 PM UTC

jere wrote: post #52

>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 a…

Totally. I like Angular a lot, and I'm not blind to its drawbacks. The code sample in the blog post has room for improvement, but I don't understand what he thinks it demonstrates. Yeah, it's a little weird that controllers don't expose their own functions, that instead you attach functions and data to the $scope. But if that's the way you do it Angular, I don't understand what makes it a bad habit to learn.

Re: Why junior developers are learning bad habits from Angular

#137

Post by cheshire137 » Thu, Jan 29, 2015, 10:22 PM UTC

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

Re: Why junior developers are learning bad habits from Angular

#138

Post by bmm6o » Fri, Jan 30, 2015, 4:12 PM UTC

bmm6o wrote: post #136

jere wrote: post #52

>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 a…

Totally. I like Angular a lot, and I'm not blind to its drawbacks. The code sample in the blog post has room for improvement, but I don't understand what he thinks it demonstrates. Yeah, it's a little weird that controllers don't expose their own functions, that instead you attach functions and data to the $scope. But if that's the way you do it Angular, I don't understand what makes it a bad habit to learn.

He's added a link in the comments to http://csharperimage.jeremylikness.com/2014/11/the-top-5-mis..., which makes a strong argument. It's too bad he couldn't articulate this in his post.