[quadratini]

Angular abstractions leak everywhere: http://stackoverflow.com/questions/18826320/what-is-the-hash... http://stackoverflow.com/questions/16935766/run-jquery-code-... <- "You might need this timeout to be sure its run after DOM render." wat

- You have to do everything the "angular way". Timeouts, intervals, http, modules, angular.toJson. It's a pain. Why can't I use the regular setTimeout, or ES6 or Common JS modules, or JSON.stringify?

- You end up having to dig inside the source code to debug issues with Angular.

- You basically HAVE to understand the digest cycle.

- Its way of doing templating is crippled in the sense that it's not as expressive as javascript.

- Honestly I think it's for people who doesn't like javascript and its ecosystem (npm).

React isn't alike angular because that's the point. React embraces javascript whereas Angular doesn't. If you want a http library use one of your choosing from npm, like axios. You want to use Common JS modules? Go ahead.

[iends]

Angular.js is a framework, so it's no surprise that you have to understand how it works and use its idioms.

It's also batteries included, so it makes certain choices for you in exchange for cleaner integration. These are choices you have to make for yourself when using React. This is freedom at the cost of integration. Framework decisions always involve deciding on this tradeoff.

[JohnMunsch]

- The answer to why you have to use $timeout, $interval, etc. is simple. If you do it that way then AngularJS knows when you might have made a change in the scope and can look to see if there are updates to be made in the UI or watches to fire. It is a convenience system to avoid you having to tell the system that new data arrived from an earlier call to the web server and that you assigned it to a variable that also happens to appear in multiple spots on the page. React does not "embrace" that issue either. It does not magically know when to update itself on timer events or AJAX responses without some help.

P.S. You can absolutely use anything you like other than the provided wrappers. If you do, just call $apply() afterward. That's the signal to AngularJS that you changed something that might require it to do updates elsewhere.

- In two years of doing AngularJS work as a full time job (plus weekend projects) I have never ended up digging through the source code. Nor have any of the people working for me on my team at work. So the idea that you have to do that is patently false.

- I'm not sure how much is there is to understand about the cycle. It happens whenever events fire which indicate changes might have occurred. Later, when browsers directly support watching variables for change, I'm guessing there will be no need for it anymore.

- Hmm. The templating thing is an interesting way of thinking about it. Yes, it is crippled in one sense because it doesn't have the full expressiveness of JavaScript. I can see that. On the other hand it's elegant because you don't have to drop out of your HTML to do your templating work somewhere else using a completely different syntax or location. I think there are really good arguments to be made on both sides of this argument.

- Fascinating. Almost all of my AngularJS code is JavaScript. The portions of the code devoted to keeping AngularJS happy are a very small portion of the total. Based on what I've seen of 2.0 controllers, services, etc. are simply standard JavaScript objects so it seems a hard argument to make that they aren't fully embracing JS.

- And the final argument is one of my favorites. I've seen it over and over again, "Don't use a framework at all! Cobble together your own thing out of best-of-breed pieces to make a system." That may work well for an individual (though I think it will not) but for a team?!? No way.

I'm not anti-React or anti-Ember, but I am anti-throw something together based on intuition and try to use it to build something real.

[quadratini]

It was a rhetorical question. I understand why we need to use a special version of setTimeout or a special HTTP module, but the fundamental problem is that Angular's "reactive javascript" abstraction leaks in a way that you're forced to do it the Angular way.

React's abstraction also leaks, which is evident when it doesn't automatically know to update itself so you have to call `setState`. But I'd choose this set of leaky abstractions over Angular's. Plus it makes it easy to spot all the places where the UI can change which is a huge plus for debugging. The beauty of React's set of abstractions is that it doesn't force you to do things a certain way (use $http, use $timeout) or use observables which embraces mutability.

Also to further my point that Angular (and any other framework that provides templating) doesn't embrace javascript, every time you use `ng-repeat` you're not doing javascript. You can't put a debugger in the middle of the loop to check the scope. You can't use Immutable-js because `ng-repeat` loves arrays. (Ok you can convert the immutable to an array before hand, but then when it changes you'd have to incur an expensive rerender of the list) You can't use static analysis tools.