If Angular doesn't float your boat, that's fine. For those wondering if this is true, it's not. Views in Angular can interrogate their controller for model data, and they can fire events into the controller. The controller doesn't know about the view (or even if it is hooked up to a DOM instead of a test runner). You can reuse a view with a different controller (provided, of course, the controller supports the same operations). I don't believe that this level of coupling is harmful. In fact I think it separates these concerns nicely.

The view is written in HTML, you declare the bindings with moustache-style templates or with attributes. Some people get really hung up on this, but the declarative UI is not Turing complete, so it's not really like embedding PHP at all.

By the way, I like Backbone too, and I use Underscore everywhere. Congratulations to all involved on reaching an important milestone and creating tons of value for everybody.

> You can reuse a view with a different controller

Then the examples on the site are really misleading, given that they hardcode the controller name in the example views.

EDIT:

To give an example of what I object to, this is cut and pasted from the Angular homepage:

    <div ng-controller="TodoCtrl">
      <span>{{remaining()}} of {{todos.length}} remaining</span>
      [ <a href="" ng-click="archive()">archive</a> ]
      <ul class="unstyled">
        <li ng-repeat="todo in todos">
          <input type="checkbox" ng-model="todo.done">
          <span class="done-{{todo.done}}">{{todo.text}}</span>
        </li>
      </ul>
      <form ng-submit="addTodo()">
        <input type="text" ng-model="todoText"  size="30"
               placeholder="add new todo here">
        <input class="btn-primary" type="submit" value="add">
      </form>
    </div>

First, it hardcodes the controller name. This, to me is configuration information - part of setting up routes - that the view should not know. Then there's the ng-click and ng-submit bits. More configuration that I really don't want in my views. It also seems to declare the model to update in the view?

This is what I meant about tight coupling to the views.

Good questions. I fully support DOM Spaghetti Aversion, but Angular's approach is quite different from PHP. I'd hate for people to dismiss it because they heard its the new PHP or because it cosmetically resembles an anti-pattern.

To answer your specific concerns, you can in fact imperatively bind Angular controllers to route views in the app's configuration block. However, this approach doesn't always make sense—you can have multiple apps in a page, each app having multiple controllers, so they can't all use the URL as the engine of application state. In cases like this you can your view as a directive, and then you can inject the appropriate controller (in fact this is exactly how ng-view works with the router).

Or, you can take the approach quoted above, and use an XML-like declarative configuration language to describe the view and its relationship to whatever happens to be its controller, and let the compiler generate the appropriate HTML for you. (I'm kidding, it's HTML all the way. But in Angular, the view describes its own structure, appearance and behavior, the controller is concerned with mutating state and not DOM manipulation.)

I'm not trying to evangelize, just put some good information out there. Backbone's templates, as I recall, use ERB-style syntax to push values and imperative code into templates, which then set up their models (http://backbonejs.org/#FAQ-bootstrap). I think you agree it would be unfair to put down Backbone as the new PHP based on that fact that its templates let you write in that style.

Enjoy!

You know, it's really nice to work with. I like the structure Angular provides, but I tend to agree. It doesn't feel entirely "right". Maybe I just need to get over it.