> Yes, but even from a user's point of view I'm delighted when I use stateless web "apps". Facebook is an excellent example: There's quite a lot of AJAX-magic, but it still feels (and functions) as a stateless web site.
> No silly "double loading";
What does double-loading mean?
> easy to bookmark; links I can Cmd-Tab;
The primary goal of the Ember router is to provide this functionality out of the box. The reason you get a single callback with an object regardless of how you arrived at a given state to is to ensure that entering through the router (cmd-tab, bookmark) is the same as transitioning in the app.
If you use the router with the Ember `{{action}}` helper, there isn't really any way to have URLs that don't have the features you desire.
> the page doesn't magically fail when my internet connection is broken.
I don't know exactly what this means. Surely when your internet connection is broken, regular "stateless" pages don't work either?
Are you just saying that there are fewer problem states as an end user? Either the page loaded or it didn't? I've personally had a ton of issues with Facebook Ajax requests failing when I'm in a flaky connection scenario resulting in a generally unusable page.
Basically, a web app that is usable (or at least readable) before all your JavaScript initialization is done. With Facebook, as soon as the HTML and CSS hits your browser it can render a more or less complete page. With Ember.js, that doesn't happen until the application is initialized and all your templates are rendered.
To be fair, that totally depends on how the application is written. You can have server-side-rendered page with single-page application, with or without Ember.js.
With Ember.js the routing framework is client-side and Ember.js stores all dynamic values in the URL fragment. The server doesn't see enough information to render a page, even if you were willing in theory to duplicate your rendering logic server-side.
You can use HTML5 pushState in Ember.js [1] and Backbone so application state is captured in actual URL path instead of URL location hash. The server can see enough information to render a page.
> No silly "double loading";
What does double-loading mean?
> easy to bookmark; links I can Cmd-Tab;
The primary goal of the Ember router is to provide this functionality out of the box. The reason you get a single callback with an object regardless of how you arrived at a given state to is to ensure that entering through the router (cmd-tab, bookmark) is the same as transitioning in the app.
If you use the router with the Ember `{{action}}` helper, there isn't really any way to have URLs that don't have the features you desire.
> the page doesn't magically fail when my internet connection is broken.
I don't know exactly what this means. Surely when your internet connection is broken, regular "stateless" pages don't work either?
Are you just saying that there are fewer problem states as an end user? Either the page loaded or it didn't? I've personally had a ton of issues with Facebook Ajax requests failing when I'm in a flaky connection scenario resulting in a generally unusable page.
Can you elaborate on what you mean here?