Live data from Hacker News

Why junior developers are learning bad habits from Angular

javascriptkicks.com

121–130 of 138 posts

Re: Why junior developers are learning bad habits from Angular

#121
post #109

Earlier quoted context omitted.

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

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

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.

Re: Why junior developers are learning bad habits from Angular

#122
post #96
post #87

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, dir…

which, I think, was the entire point of this article. But it speaks a lot to the angular community, and the heavy hand Google has used to build and maintain it, that the top half of the comments on this page center around people intentionally not seeing this

I don't think I can agree with that assessment. Alternatively, is the top half of the comments saying "Angular is complicated, but not unnecessarily so for building large web apps with big teams?"

Re: Why junior developers are learning bad habits from Angular

#123

Earlier quoted context omitted.

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

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

Based on history (Angular published in 2009, Bootstrap in 2011), that's a bit revisionist isn't it? It's the open web stack that's incompatible with Angular---as well it should be, since each piece of that stack is trying to solve a part of the elephant and Angular was architected to solve the whole elephant.

That having been said, the criticisms about it being an enterprise framework that's hard to move off of are spot-on. But lots of people prefer a one-stop solution to cobbling together an open stack---less flexibility, more out-of-the-box functionality.

Re: Why junior developers are learning bad habits from Angular

#124
post #53
post #33

Earlier quoted context omitted.

Well, we could decide as an industry that we really need to fix the code-in-web-browsers problem, and then fix it with a language which encourages safety and reliability. The fact that we haven't done that supports the OP's point.

But the same can be said about C / C++ with undefined and quirky behaviour. Even when the desire to replace them is there, it's near possible given the present situation.

Well, actually: http://www.rust-lang.org

Everything is possible. One step at a time. C++ and JS belong with COBOL.

Re: Why junior developers are learning bad habits from Angular

#125
post #69

Earlier quoted context omitted.

This article only did one thing for me - demonstrate that the author himself doesn't understand Angular or the problems. I don't know Angular that well myself, but the author knew anything more than I did, he'd be able to spend the extra 30 seconds to write the refactored code. Dismiss this article. It's a waste of time and energy. In fact, I really shouldn't even be wasting my time commenting on it.

>This article only did one thing for me - demonstrate that the author himself doesn't understand Angular or the problems. Seems pretty evident from the horrible jankiness of this blog. Heavy as shit and it loads on the 5th try.

Ad hominem. I can't really comment on the article itself since I don't understand anything about Angular, but let's do our best not to just throw a bunch of random stuff at the wall and hope something sticks just to justify our lack of understanding of the author's point.

Re: Why junior developers are learning bad habits from Angular

#126
post #41

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

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.

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.

Re: Why junior developers are learning bad habits from Angular

#127

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…

I think what alot of people don't think about is that "proper / correct engineering principles" don't necessarily translate to creating successful projects / companies. If your goal is to nitpick about the reasons why a specific framework is not right for the job, then "mission accomplished". If your goal is to create amazing products / services. And are willing to do anything to accomplish that, then sadly I think y…

Essentially this.

Angular may be monolithic and less flexible, but if a young company gets to prototype faster with it and as a result survives to second- and third- funding rounds, they can afford the engineering hours to re-implement their UI from scratch.

Success (and its associated revenue) solves all engineering problems in the long run.

Re: Why junior developers are learning bad habits from Angular

#128
post #34
post #15

Earlier quoted context omitted.

Settling for JS in the first place says something about the software industry in general. Let alone any MVC frameworks-of-day.

If that were true there would be no such things as CoffeeScript and TypeScript. The market settled on JavaScript, not the software industry. The software industry is doing what it can with the hand the market dealt them. It's not like x86 is an awesome architecture, but here we are.

Market doesn't care what is running the products. The problem is dodgy organizations over-promoting wrong choices (W3C, Google, Mozilla etc.).

Microsoft tried to fight back with Silverlight, but given up.

Re: Why junior developers are learning bad habits from Angular

#129

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

I can't disagree more with the author's assessment of Angular's dependency injection.

DI in Angular was the first time DI made sense to me. And it makes testing really staightforward: test the component you're on top of, mock and fake the rest. Lots of boilerplate, but no actual hassle.

Re: Why junior developers are learning bad habits from Angular

#130
post #125

Earlier quoted context omitted.

>This article only did one thing for me - demonstrate that the author himself doesn't understand Angular or the problems. Seems pretty evident from the horrible jankiness of this blog. Heavy as shit and it loads on the 5th try.

Ad hominem. I can't really comment on the article itself since I don't understand anything about Angular, but let's do our best not to just throw a bunch of random stuff at the wall and hope something sticks just to justify our lack of understanding of the author's point.

Believe me if the blog wasn't built using angular I wouldn't have said anything.
Post reply on HN