Live data from Hacker News

Criticisms of Angular

leanpanda.com

101–110 of 150 posts

Re: Criticisms of Angular

#101

Earlier quoted context omitted.

I agree with this, I've been using Angular for a while now and like it. Every time I read these criticisms of Angular, I always think...compared to what? For example, I don't find fixing occasional performance issues when using two way binding a big deal. Two way binding makes my UI code much more concise and free from bugs concerning keeping models and the DOM in sync. I've worked with Backbone before for instance a…

Compared to Ember. Most of the time all you need is a computed property. It simplifies the code base and allows the framework to make optimizations where it needs to. If you really need a two way binding you can always do it with a computed alias.

Are there any cons to the way Ember does things?

Re: Criticisms of Angular

#102
post #65

Earlier quoted context omitted.

Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. As someone who's going to need to make a recommendation soon about whether or not to use Angular on a new project, this part worries me. The apps my company buil…

Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. However, I don't think that the performance hit you would take would be that noticeable depending on the implementation. Here's a jsperf test that can demonstrate angular performance with 10k watchers: http://jsperf.com/angularjs-digest/72 Chrome 45 gave me about 3.2k ops/sec

Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI.

Totally agree, but my business is auto-generating fully-featured applications based on database schema inspection and a code-generation wizard, for clients with large enterprise databases. So the app has to work reasonably well with out-of-the-box generation before we start tweaking it to customize and improve the UI for the most important tables and most common workflows.

Thanks for the jsperf test. It's good to know the range of results for different browsers. Our app needs to run on everything, including Mobile browsers, and that test proves that we can't get away with using the typical Bootstrap responsive "hide some columns for xs" approach. We need to not generate markup for most of the columns at all. That means we're going to have to enhance our generation wizard to let us specify, per-table, device-size-specific column lists instead of just a single column list.

Re: Criticisms of Angular

#104

This is a rehash of the same problems that have been circulating for years [0]. There is literately not a single original thing here. Most of these issues are gotchas that can easily be avoided once the developer is aware of them (such as scope inheritance / dynamic scope which is due to Javascript Prototypal Inheritance [1]). What's ironic is that angular 2 is fully rewritten in part to fix all of these issues, but…

This is the comment I was looking for. There was definitely a lot of hand-wringing around the migration path from Angular 1 to 2, but I think the resolved the issue quite nicely.

I've used it in production in a few scenarios and it's worked just fine. They're fairly complex applications and performance hasn't been an issue. Granted, with the author trashing Angular and then talking about how awesome their React article is going to be I think we can all see where this is heading.

Re: Criticisms of Angular

#105
post #103

Is Angular really that popular? From google trend, Jquery is still 3-5 times more popular then Angular, React. What do you guys think? https://www.google.com/trends/explore#q=jquery%2C%20angularj...

In terms of Single Page Application frameworks, Angular is very popular. Comparing it to jQuery doesn't really make sense as jQuery is a utility library and doesn't support all of the features that Angular has.

Re: Criticisms of Angular

#106
post #103

Is Angular really that popular? From google trend, Jquery is still 3-5 times more popular then Angular, React. What do you guys think? https://www.google.com/trends/explore#q=jquery%2C%20angularj...

That's hardly a fair comparison. jQuery is a library and Angular is a framework. IIRC, Angular depends on (at least a subset) of jQuery, so it could only approach usage and never exceed.

Re: Criticisms of Angular

#107
post #74

Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. I like using nearly straight up HTML as my template. I do this in Django, so why not in Angular? I like that I don't need to render things…

IMO there is no problem with Angular, except when people use it as a square peg with a round hole. It's ideal for your use case - lots of data entry, forms, etc. etc. But then someone tries to write a blog platform with it, or something. I think part of the problem is that everyone wants there to be The Next Thing that will solve all problems, when that doesn't exist.

This is the problem with angular. Why are people using it as a square peg with a round hole? Is it because people are stupid or is it because angular is stupid?

Looks to me angular is a round peg disguised as a square one.

Re: Criticisms of Angular

#108
post #61

Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. I like using nearly straight up HTML as my template. I do this in Django, so why not in Angular? I like that I don't need to render things…

I've been working pretty much exclusively with Angular for the past 18 months on some high volume financial processing systems. Shipped 3 codebases that would probably be considered 'large'. It's been one of the best development experiences I've ever had. The learning curve is steep, but when you get into the groove, when it finally clicks, then you can really take off with it. I love the tooling (node, Yeoman, Grunt…

We have been dealing with a large angular front end and our big problem is really more along the lines of using watchers to take the place of what should be handled by a domain model. I don't think this is a problem with Angular but an issue with JSON. I have yet to find something that can take serialized JSON and hydrate a domain object in javascript.

Re: Criticisms of Angular

#109
post #72
post #34

Earlier quoted context omitted.

> They kind of solve the same problem no they don't. That's a fundamental mistake to say that. DI is about inversion of control , modules don't do that.

IoC is the way that DI solves the problem. But the problem is dependency management - and there are other ways around that.

The difference is that modules systems specify statically resolved dependencies between code files. DI and IoC specify dynamically resolved dependencies between instances of objects. They are both useful, but they both solve different problems.

Re: Criticisms of Angular

#110
> Problem #1: Scope inheritance and dynamic scoping

Easily solved by using the controllerAs syntax

> Problem #2: Dirty checking

One time binding to the rescue here. Been available for a good while now. Dirty checking does suck though but is usually not a deal breaker.

> Problem #3: Dependency injection

The authors main problem here seems to be with problems minifying the code. All one needs to do is to pass in an annotations array which is an established best practice. So instead of controller('ControllerName', function($scope, $someService){}) one should use controller('ControllerName', ['$scope', '$someService', function($scope, $someService){}]) there are other more readable ways to do this such as $inject but I digress.

> Problem #4: Pointless complexity

This is debatable and more a matter of opinion. I disagree and think the glut of the authors woes come from not taking the time to understand the framework properly. The learning curve is steep yes but I've used a TON of javascript frameworks and Angular consistently comes out the winner long term in maintainability and stability.

> Problem #5: Server-side rendering

Isomorphic javascript to the rescue here. React does it better in this case but its available if you need it. Angular is a single page web app. If you knew that going in and have a problem with it now... well lets just say that its important to understand the trade offs that come with any technology one chooses to include in their stack.

> Problem #6: Angular 2

Yes this was a concern, and then the angular team listened to the outcry from the community and now have been developing a migration path for users of the 1x code. They have also dedicated an entire team to continue development on the 1x codebase for as long as it remains popular thats why there are two angular websites.

While I admit that angular isn't perfect (literally nothing is) nearly all of the authors criticisms are due to lack of following best practices. You can find a pretty good summation here: https://github.com/johnpapa/angular-styleguide

Post reply on HN