Yeah, it’s true that the URL/browser is basically the stack manager. There is however one difference:
With UINavigationController
s, you can indefinitely push the same controller on the stack. In Ember this doesn’t work because the router destroys the previous view when rendering into the same outlet, and the controller is a singleton.
This is partly because there is a one-to-one relationship between the current controller and the URL. If we could break this relationship, more complex views would be possible IMHO.
For example: An interface that layers the current controller on top of the previously visited controllers. When transitioning to a new route, the new controller is rendered on top of the previous one, even the same controller class with a different model. The URL does not need to reflect the whole tree, it can just display the current active item. When reloading the URL, all the intermediary controllers are not recreated, but merely the first and current one.
EDIT
The more I think of this, the more I start to question the one-view-at-a-time outlets and the way of toggling child views.
{{if greetVisible}}
Hi there
{{/if}}
It’s nice to have code like this because it enables very rapid development. But it also creates some form of a lock in. You can’t easily animate in/out the childView and stacked views etc. can’t be done easily.