The view asks the controller for data. The controller might delegate that question to the model. The view shouldn't care whether the data was delegated or not; it should just get a response from the controller.
Seems like textbook object-oriented design. Otherwise how will the views update automatically when the models change? The views shouldn't know what models it needs. In fact, it seems they shouldn't know that models are a thing at all. It's just data from the controller.
A view calling controller.model.property is MORE tightly coupled than controller.property. The controller is tied to the view and the model as it's supposed to be. The view is not tied to the model.
No, it's not. Because a single controller over its lifetime can be bound to many different models.
The controller is glue. It brings together whichever model is appropriate at the moment with whatever view is appropriate at the moment, and makes decisions about when to change those things.
How is the controller not the data as far as the View is concerned?
For the sanity of the view, the controller is the single point where it can get the data. It shouldn't know the nitty gritty details about where it came from, whether it's a "model," or anything else. The view is just, "Gimme the data, controller! Gimme!"
This principle is just as valid in Ember as it is in Rails. The only difference I see is that because the controller and view have to live forever, so to speak, it makes more sense for the view to pull data from the controller rather than have the controller push data to the view.
Maybe think about it this way. How is this any different than rails, really? In Rails you set goddamn instance variables in your controller actions. The view and controller are straight-up sharing state.
How is that less coupled?
This would be like the controller exposing getting and setter methods and instead of typing
<% @users.each do |user| %>
<li><%= user.name %></li>
<% end %>
you'd type <% controller.users.each do |user| %>
<li><%= user.name %></li>
<% end %>
It seems like Ember does some "nice things" to handle the common cases and that there are additional assumptions, like maybe one model per controller (not sure I understand that), but there you go.Ember seems less coupled all around than Rails and because of its long-running nature needs the view to poll the controller.