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