> I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time
I take it that all of your applications involve public content with minimal if any enhancements to logged in users?
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"; easy to bookmark; links I can Cmd-Tab; the page doesn't magically fail when my internet connection is broken.
I am aware of that most the issues with single-page applications comes from the applications themselves, not the architecture (i.e. is the developers', not the technology's fault) but there seems to be quite a lot of complexity with this architecture. I've seen very few applications that handles all of these issues.
> 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.
If you do it right, you can support bookmarking pages and cmd-clicking links in your web apps.
Also, an Ember app could be designed to function seamlessly with an intermittent connection where a normal website would just be unavailable. Also, many pages will just continue to function without doing any extra work, provided the user doesn't post to the server until the connection comes back.
I take it that all of your applications involve public content with minimal if any enhancements to logged in users?