The controller is in fact separated. The "ngController" you see referenced in the markup is the link between the view and the separate controller. Any MVC framework you could hold up as an example of proper "separation of concerns" will necessarily have the same link, even if it's implicit. Sometimes it's defined in the controller, sometimes the link is defined in the view, and sometimes you don't see it defined, but it's still there. (of course, we all know explicit is better than implicit)

Right, but doing it this way means both the view and the controller know too much. Why should a view know about how it is going to be used? Also, I'm guessing if you give this to a designer his/her eyes are going to glaze over.

No, the link here is only in the view. The controller doesn't "know" about the view. This is opposite but functionally equivalent to have traditional server-side MVC frameworks handle this, which is to declare the view in the controller or the routing (which you can also do in AngularJS, you actually typically declare both the view and controller in the routing). But the point is, you have to declare the link somewhere. Declaring it in the view is no less proper than declaring it in the controller.

Having said all that, I'm really impressed with React and look forward to checking it out and using it in combination with Backbone. AngularJS definitely has its share of pain points. It's just that where the controller is linked to the view is not one of them.

(By the way, I'm upvoting you since I don't see anything particularly offensive or improper about your comment. We're just disagreeing. Not sure why you're being downvoted. )

You don't actually ever need to explicitly specify the controller in Angular views. Usually in angular apps, the controller is specified by the routing provider (in JS), along with the view (template path).

In small examples (ie when not using angular routes) it is easier to explicitly specify the controller.