Criticisms of Angular • Hacker News Board

Re: Criticisms of Angular

#91

Post by jffry » Wed, Sep 23, 2015, 3:01 PM UTC

DougWebb wrote: post #59

fein wrote: post #37

Earlier quoted context omitted.

Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if. I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5. Edit: After fully reading through this blog post; it's almost all wrong. Dirty Checking: Yes,…

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…

In addition to what others have said:

If the individual cells in your grid aren't changing dynamically, you can use a one-time-binding[1] which will improve performance by removing the watchers after the expression is populated.

You can also always use a directive to do the DOM management yourself, and still use Angular-y templating in the rest of your app.

[1] https://code.angularjs.org/1.4.6/docs/guide/expression#one-t...

Re: Criticisms of Angular

#92

Post by 3pt14159 » Wed, Sep 23, 2015, 3:05 PM UTC

seanwilson wrote: post #85

IgorPartola wrote: post #45

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

Re: Criticisms of Angular

#93

Post by bryanlarsen » Wed, Sep 23, 2015, 3:06 PM UTC

cloakandswagger wrote: post #86

coldtea wrote: post #75

Earlier quoted context omitted.

> 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. React solves all of those in a cleaner way. > I like using nearly straight up HTML as my template. And yet you don't. You use Angular-iz…

I work with React daily and love it but will freely admit that using it for simple data-binding for input heavy forms is a gigantic ass-pain. If you're using Flux, you end up with an immense amount of boilerplate action and store code around every input field. The other option is to violate the model, make all your inputs uncontrolled and have boilerplate onChange listeners for each one. Choose the right tool for the…

I've got a React app which is basically just one giant form. My inputs are not uncontrolled, I use boilerplate onChange listeners, and I'm not violating the "model".

Re: Criticisms of Angular

#94

Post by davexunit » Wed, Sep 23, 2015, 3:09 PM UTC

code_sterling wrote: post #64

lhorie wrote: post #55

Earlier quoted context omitted.

> it just seems that people get scared of the documentation and run away before they really give it a try Anedoctally, as the author of another JS framework ( http://mithril.js.org ), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fu…

I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven to be very maintainable in the long run, especially for larger and more complex solutions. Additionally, the cost of migrating an app is much much higher. So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.

I love Mithril's (and other's) "build a DOM in code" approach. Traditional templating systems are always limited domain-specific languages that add lots of complexity for things that should be simple, template "partials" and iteration come to mind instantly.

Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views.

On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.

Re: Criticisms of Angular

#95

Post by mercurial » Wed, Sep 23, 2015, 3:09 PM UTC

troels wrote: post #4

stupidcar wrote: post #2

When the author doesn't understand the difference between a module system and a dependency injection system, it's hard to take the rest of what he says seriously.

They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in javascript.

Dependency injection has merit in any language. Throw DI out of the window, testability goes with it.

Now, on the matter of IOC containers, you can easily roll your own or use a sane one (eg, Guava in Java).

Re: Criticisms of Angular

#96

Post by spmurrayzzz » Wed, Sep 23, 2015, 3:10 PM UTC

rbalicki wrote: post #43

Valid criticisms of Angular include that it gives you enough rope to hang yourself, that the documentation/tutorials teach you to code Angular in a bad way (abuse the $scope object, etc.) in the interest of making it "easy" and that the terminology and symbols used can be simplified. However, once you learn to avoid Angular's pitfalls, it's a very powerful tool for creating large apps that do not collapse under their…

One of the trends I've seen in my own hiring is that many Angular devs lack a solid understanding of fundamental JavaScript (closures, prototypes, functional programming, DOM API, async patterns, et al). This may be a function of how much the framework is able to abstract away from the user.

This dearth can lead to lots of code smells, bugs, antipatterns, and other grenades that can present significant problems at scale no matter what framework you choose to go with.

So if it's true that many Angular apps have problems at scale — one hypothesis would be that it may be a reflection of the selection bias of those who choose to use the framework. Which is not to say that advanced JS people aren't using the framework (they clearly are) but anecdotally, upwards of 90% of the Angular-based devs I've interviewed or interacted with personally lack an understanding of many of the aforementioned JS fundamentals.

Re: Criticisms of Angular

#97

Post by lhorie » Wed, Sep 23, 2015, 3:12 PM UTC

code_sterling wrote: post #64

lhorie wrote: post #55

Earlier quoted context omitted.

> it just seems that people get scared of the documentation and run away before they really give it a try Anedoctally, as the author of another JS framework ( http://mithril.js.org ), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fu…

I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven to be very maintainable in the long run, especially for larger and more complex solutions. Additionally, the cost of migrating an app is much much higher. So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.

Would you care to elaborate on the maintainability aspect? I've worked with various "build DOM in code" approaches too, ranging from anywhere between Ext.js to HTML string interpolation/concatenation in jQuery and I think a lot of approaches do suck (some more so than others).

One major problem with older "build-DOM-in-code" approaches was ability to integrate to third party libraries, but I feel that this problem has been solved by newer frameworks (e.g. via lifecycle methods/mixins in React, `config` in Mithril, etc).

Personally, I find that mapping the DOM structure onto Javascript a la Mithril, React, et al works out better than mapping scopes and closures and logic onto HTML (a la Angular), simply because it's easier to refactor code that is, well, code, rather than something that tries to emulate having programming-language-like properties in HTML by shipping its own quirky implementation of scopes, expression parsers, compiler, etc.

I disagree on cost of migration. It's not exactly trivial to migrate from Angular to any framework that I know of, for example, especially once you start using things like form validation flags or filters. The only migrations that sound somewhat straightforward to me are Meteor/Ember (since both use Handlebars flavors) and - perhaps ironically - React/Mithril (assuming JSX/MSX), but for mostly anything, you're pretty much stuck with manually porting framework-specific syntax. With that being said, it's not necessarily impossible. I know of success stories of people porting non-trivial codebases from Ember to Mithril and even from jQuery spaghetti to Mithril (via its template converter too). At the end of the day, I think it comes down to tooling. With React's renderToString or mithril-node-render, it's quite feasible to automate a large portion of the work of porting templates away from these newer frameworks, should you need to do so down the road.

Re: Criticisms of Angular

#98

Post by squeaky-clean » Wed, Sep 23, 2015, 3:12 PM UTC

fein wrote: post #37

nateabele wrote: post #30

So, they trot out the same tired arguments against Angular that people have been making since the beginning, and this makes the front page where people engage in serious discussion about it? Did I miss some subtle novelty about this post, or is Angular ennui just that popular on HN?

Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if. I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5. Edit: After fully reading through this blog post; it's almost all wrong. Dirty Checking: Yes,…

Seriously, 3 different ways to fix their "Problem #1"

1) Define $scope.obj in the controller, instead of letting ng-model create it for you. [0]

2) Bind to $parent.obj in the inner scope (not necessary in later versions of angular) [0]

3) Upgrade to a modern version of Angular.

[0] https://jsfiddle.net/e924n237/

Re: Criticisms of Angular

#99

Post by tonyhb » Wed, Sep 23, 2015, 3:25 PM UTC

DougWebb wrote: post #59

fein wrote: post #37

Earlier quoted context omitted.

Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if. I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5. Edit: After fully reading through this blog post; it's almost all wrong. Dirty Checking: Yes,…

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…

React + Redux: https://github.com/rackt/redux

You will not regret it.

Re: Criticisms of Angular

#100

Post by lloyd-christmas » Wed, Sep 23, 2015, 3:25 PM UTC

ebbv wrote: post #90

IgorPartola wrote: post #45

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 enjoyed Angular 1.x. But I feel burned really badly by 2.0. I learned 1.3 shortly before 2.0 was announced and it was a really frustrating experience to have just felt like I learned this tool and then have everything thrown out the window. So, I'm not excited about learning 2.0 and haven't yet. I believe the claims that it's faster/better, but the way they threw everything out the window with 2.0 makes me concerne…

You can upgrade bits and pieces as you learn it: http://angularjs.blogspot.de/2015/08/angular-1-and-angular-2... It will end up being no different than any other tech learning curve without breaking your application.