Ben Nadel

I don't think his criticism is too harsh.

Two of the main problems I had with angular - the template syntax and the way the digest cycle worked, both contributed to its scaling factor.

The template syntax meant you would always wonder what a parameter meant when passed to a directive. Essentially, all parameters passed to a directive were strings, but angular would parse some strings to mean "the property of a parent scope", and some more convoluted variations of that(check out https://docs.angularjs.org/api/ng/service/$compile#-scope-). Furthermore, using the recommended ng-controller directive created great spaghetti code, with template blobs where the current scope is almost impossible to track. Applying multiple directives to the same element sometimes required special parameter parsing, which further made the situation confusing. This confusion meant the more stuff you had, the more time you had to spend carefully memorizing it all so you knew what was going on.

The digest cycle fundamentally limits angular's scale. It was designed with some scale in mind at first - a digest cycle triggered at a specific scope would only run watchers under that scope, thus limiting the effect. I assume they hit the problem that there was no way to define explicitly "global" watchers, or to tell another scope to update itself. This issue apparently crept into the development of angular and local digests were pretty much abandoned in favor of using scope.$apply(), which triggers a…

> I consider myself to be a reasonably good js developer, but the internals of AngularJS are overwhelmingly non-approachable.

Same here. I'm just getting up to speed with Angular. I spent the past weekend developing a web-app to manage our internal test-process. I like it a lot, I managed to create an incredibly complex and interactive web-app in two days.

Well, I say I like it a lot, I like the idea a lot: data driven mark-up, separation of concerns, etc.

However when it goes wrong it's incredibly difficult to step through the Angular code to work out what on earth is the cause of the issue.

It took me several hours of poking around trying to get this tree-view directive to work:

http://ngmodules.org/modules/angular.treeview

First to try and work out why the directive wasn't being initialised, then why the parameters were coming through with different names of the properties compared to what the original source expected (ngTreeModel rather than treeModel for example). Then, why on the inner elements of the tree the properties coming through were named as expected!

So exasperated I head over to the documentation for directives, and, yeah, horrible... incredibly dry and terse.

I never quite got to the bottom of the issue, and have deferred working it out until I know Angular a bit more (var treeId = attrs.ngTreeId || attrs.treeId).

But I can't deny that this thing is incredibly powerful, so I think it's worth persevering with. But yeah, some better docs and…

Whenever someone asks me about learning and using AngularJS I link them to this helpful diagram:

http://www.bennadel.com/blog/2439-My-Experience-With-AngularJS-The-Super-heroic-JavaScript-MVW-Framework.htm

I've been using AngularJS for more than three months now and feel like I finally reached a tipping point where the months of agony are starting to pay off. Before switching to AngularJS I used Backbone.js extensively and tried out Ember.js.

The biggest thing to realize with AngularJS, I think, is that your entire front-end "stack" needs to be re-evaluated. Having been using CoffeeScript for a long time, I actually ended up taking it out of all my environments so that it would be easier to debug and understand my JS code as it is "interpreted" by AngularJS. I also had to force myself to stop thinking in jQuery and learn to live with jqLite (which naturally pressures you to exercise restraint with by-hand DOM manipulation, angular.element, etc.,.). While it felt unnatural to me at first, writing directives became second nature after I understood how to properly use them and how powerful they really are. When evaluating JS libraries to include in my code, I now find myself asking whether they can be easily integrated in the "AngularJS" way (making D3.js work with AngularJS was great practice).

Secondly, we all need to face and accept that the current AngularJS documentation is crap and it doesn't look like it's going to get better anytime soon. In addition to that, I…

I agree with grellas that while Digg or Reddit (really their legal counsel) could technically claim a copyright in the legal written work that you are adapting for your own use, realistically suing you for copyright infringement on their terms of use and privacy policies wouldn't be worth their time, and you could potentially assert a successful defense of fair use. I don't know the specifics of your business so I can't give you specifically tailored indemnity, privacy and use of information clauses for free (yet!) but that type of work is not hard for a lawyer, really shouldn't cost you very much and shouldn't take long (a couple hours). The much bigger issue in my opinion (and why copying Digg, etc long term isn't a good idea) is whether adapting their policies will adequately protect your rights and liabilities and those of your business well, especially those idiosyncratic to your business. If you just need boilerplate for the time being you can avoid this whole issue by using privacy policy and terms of use generators; I found a few here:

http://www.bennadel.com/coldfusion/privacy-policy-generator.htm

http://terms-of-service-generator.legalriver.com/

> For example angular 2 is not compatible with angular 1, so before you even learn a framework its API is different and when you finally learn it, probably is considered outdated

Angular 1 has been released in 2010 and Angular 2 in 2016. Obviously, if you started to learn Angular 1 last year it can be frustrating (specially with Angular, it's not the easiest framework to learn out there [1] [2] ). But I would say the majority of Angular developers has used it for 3 or 4 years now and most of them probably enjoy to have the chance to learn a new modern framework that fixes the design issues of the first version.

To generalize: The front-end world is surely overwhelming for the new comers (but is it not the same in all the other fields of programming?). However, after some years into it, you realize that you have mostly sticked to the same tools for years. [3]

[1] https://www.bennadel.com/resources/uploads/2013/feelings_about_angularjs_over_time.png

[2] https://i.imgur.com/5rJH3co.png

[3] https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19851a33

`setState` doesn't actually care whether you've mutated your data or updated it immutably. In fact, I just ran a quick test, and you can even directly mutate your state object and then call `this.setState({})`, and it will update. `setState` is basically a combination of "queue an update to `this.state`, and queue a re-render along with that". So, if you mutate `this.state` and then re-render, your render output would be "correct" because the state object was updated.

Where immutability really comes into play with React itself is optimizations via `shouldComponentUpdate`. The fastest way to determine if a component needs to update is shallow equality comparisons of current and next props/state, which requires that you do immutable data updates to produce new object references. Two good articles on the topic are [0] and [1].

[0] http://reactkungfu.com/2015/08/pros-and-cons-of-using-immutability-with-react-js/

[1] https://www.bennadel.com/blog/2903-why-should-i-care-about-immutable-data-in-reactjs.htm