Live data from Hacker News

Why you should not use AngularJs

medium.com

31–40 of 48 posts

Re: Why you should not use AngularJs

#31
I am not a good front end developer, however I think something like Angular is very useful to a frontend noob like me, I remember my old Jquery days, it is much easier to write modular code in Angular. You just have a template, and its controller. Easy! (For not very complicated things ofc) It might be better in other frameworks, I agree the docs are somewhat confusing, I still confuse provider-service-factory however as I said, it simplifies most of my development, and my medium sized web app runs very smoothly with Angular

Re: Why you should not use AngularJs

#32

Earlier quoted context omitted.

What would be a sane framework? Every one of them seems to have many pain points, and every other developper tells you should use X instead of Y because Z.

I would suggest an exercise which my senior suggested. Take a look at what very successful websites use. I looked at the code of Facebook and the simplicity of their code fascinates me. The only thing they seem to use is react, a requirejs like module system combined with an EventEmitter. I still don't understand the need of three layers of abstraction on the front-end level. I would love to be proven wrong, but that…

Don’t make the mistake of assuming there’s a “Right Number” of levels of abstraction. Their suitability is based on how clearly they help you interact with a system whose implementation you don’t care about.

That’s a totally human quality metric, which you can’t enumerate.

Re: Why you should not use AngularJs

#33
To be honest, this article is pretty poor, and even demonstrates the lack of understanding of Angular the author has.

The databinding capabilities is said to be at 8000+ watchers now, although not all watchers are equal. A lot of performance improvements have been made since 2-3 years ago when that post was made about the watchers, which is where that oft poorly quoted 2000 watcher number originates from.

The two way databinding complaints miss the mark - the point of them in directives was to mimic eencapsulation and what is now being known as the we component spec. Web Components are essentially what Angular directives were meant to be in absence of an official spec for browsers to implement. The point of two way databinding in inputs also are for encapsulating logic for each component.

The comments about ng-cloak and ng-bind were also flat out incorrect.

I think most of all, the author doesn't understand context - Angular was conceived during a different time for frontend, and at a different time with browser support. Five years is a long time to last in the frontend world currently, and that it will likely last at least 3 years more is surprising for a framework that has changed frontend development for the better overall.

Angular is obviously not perfect, and the core team members are quick to point out flaws in approach, or solutions that were good at the time but don't make sense going forward due to changes in the browser environment or other technologies solving problems that Angular had to solve, such as with Object.observe, ES6 modules, and ES6 promises.

I have built & architected many Angular apps over the past two years, some being very complex due to the problem space. I have found Angular to be perfectly suited to the task, and snappy to boot. I have seen very few perf problems where I could not fix them with a little work - the only one that was too difficult was dealing with editable tables with lots of data in older browsers (IE8 - 10), and I believe I could have tackled it, but I was playing more of an advisor role to another developer, and these sort of problems usually require the engineer working on the problem to understand the nuances of the code itself.

Re: Why you should not use AngularJs

#34
post #33

To be honest, this article is pretty poor, and even demonstrates the lack of understanding of Angular the author has. The databinding capabilities is said to be at 8000+ watchers now, although not all watchers are equal. A lot of performance improvements have been made since 2-3 years ago when that post was made about the watchers, which is where that oft poorly quoted 2000 watcher number originates from. The two way…

My thoughts exactly. There's nothing new or unique about this article that hasn't been brought up or debated before.

Saying that data binding is wrong because it doesn't use click handlers for a button is kinda silly...Angular allows you to do that. I use ng-click all the time on buttons. $watch is for communicating between interdependent components not handling click events.

Re: Why you should not use AngularJs

#35
post #11

I am working on a large app based on angular (not my decision - I voted against it :)), and felt many pain points already, from poor design overall, to crappy extensions most of the currents apps are using. It Kinda reminds me whole Wordpress thing. Really subpar codebase - but at the same time very easy to make simple things, and as a result - a lot of popularity. And this comes not as surprise to see so many blog p…

What would be a sane framework? Every one of them seems to have many pain points, and every other developper tells you should use X instead of Y because Z.

I would suggest you spend a few minutes reading about Twitter's Flight[1]. We've been using it for a year and it's been a pleasure.

[1] https://flightjs.github.io/

Re: Why you should not use AngularJs

#36
post #33

To be honest, this article is pretty poor, and even demonstrates the lack of understanding of Angular the author has. The databinding capabilities is said to be at 8000+ watchers now, although not all watchers are equal. A lot of performance improvements have been made since 2-3 years ago when that post was made about the watchers, which is where that oft poorly quoted 2000 watcher number originates from. The two way…

Additionally, if you have even 2000 data bindings onscreen at once, your users are likely going to be looking at too much information no matter how snappy your UI is. The more info your $watch has to deal with, the more info your users have to expect to change.

The more you want to throw on a page (say for infinite scrolling), not surprisingly, the more you'll have to be careful about how you do it. The benefit with Angular has always been that it brings the difficulty of every task down a notch or two and limits your cognitive load, very much due to its design. You still have to design your page and architect your data.

To be honest, after three years with the product, I still think Angular (1.x) was 10 years ahead of its time.

I've also come to a realization about Angular 2.0 as well: how many people are still using Windows XP? It's almost 4 versions behind, and closed-source to boot. I (as many others did) jumped all-too-quickly to the conclusion that I had to switch to version 2.0 when it came out. That's simply not the case.

Heck, even Microsoft seems to get every other version wrong. Maybe Angular 3.0 will be the time to switch.

Re: Why you should not use AngularJs

#37

> There is a fundamental rule in programming, it relates to absolutely any technology or language, this rule says that explicit is always better that implicit. Is this a fundamental rule? I thought it was something highly valued by python culture but not by, say, ruby on rails.

"Explicit" ties in to readability and from there, long-term support-, maintain-, and debug-ability. While OP did issue a blanket statement, this idea is fairly language/framework independent.

Yes, but it still isn't that clear cut. IMO and generally speaking, implicit is better when there is an obvious default behaviour that should be used in most cases. It may still be necessary to be able to override that default behaviour, but having to restate the obvious everywhere is not something that is good or desirable for the points you mention, since it will only make it harder to see what the differences are compared to the common case.

Of course, not all problems have default solutions and those should usually not have default behaviours.

To be honest, I'd rather state the rule as following when designing an API: "Do the obvious thing". Sometimes that will involve explicitness, and sometimes it will involve implicitness, but almost always it will be a mixture where some aspects are explicit and some things are implicit. The hard part is figuring out what should be which.

Re: Why you should not use AngularJs

#38

> There is a fundamental rule in programming, it relates to absolutely any technology or language, this rule says that explicit is always better that implicit. Is this a fundamental rule? I thought it was something highly valued by python culture but not by, say, ruby on rails.

I don't think so, check what ActiveSupport brings to ruby (http://guides.rubyonrails.org/active_support_core_extensions...).

TLDR: with RoR, things like `[1,2,3].third` or `foo.present?` is highly encouraged.

Re: Why you should not use AngularJs

#39
never tried it. AngularJS gave me a strong feeling of j2ee, bold, tons of reinvetions of old concepts. most of all, the authors are from google which never shipped a high quality Js/browser based product. except the original gmail.

the only problem i have with this article is: i wrote a hatre comment on angularjs about 8 months ago and got downvoted heavily, but this one just keeps earning points!

Re: Why you should not use AngularJs

#40
post #31

I am not a good front end developer, however I think something like Angular is very useful to a frontend noob like me, I remember my old Jquery days, it is much easier to write modular code in Angular. You just have a template, and its controller. Easy! (For not very complicated things ofc) It might be better in other frameworks, I agree the docs are somewhat confusing, I still confuse provider-service-factory howeve…

"a frontend noob like me, I remember my old Jquery days,"

I'm not sure how a frontend noob can have "old jquery days"! Not sure a comparison with jquery is needed. They're different enough, or do some people actually consider using Angular a "step up from" Angular? That would be funny.

Personally I prefer the cross browser/device performance benefit of jquery even for a medium sized app. Potential growth of the app's frontend needs can be met with jquery. It runs quick I've noticed even when it has a ton of work both initially and dynamically. I've thrown a lot at it, too much, and Jquery doesn't mind a high load of elements and updates, especially if you get your loading spinner graphics and display-timing sorted, complex pages can look quite smooth even on mobile. It wouldn't be wise to rule out a good performer like jquery.

Post reply on HN