It seems to me that by using node.js on the server, we should be able to share the application code, including rendering to html/dom. I have a vision in my mind of an http request coming in to the server for a given url, ember.js picking it up and rendering views/templates into html that is sent over the server. On a javascript client, that html/dom would need to be linked into ember.js on the client-side (this could be done be either regenerating the html, or by "deserializing it" in some way). Further actions on the page could be handled by the client-side javascript in normal ember.js fashion.
This approach would have several benefits. Initial response would have working html that could be rendered without having to wait on loading the application's javascript (along with dependencies) and would be workable for non-javascript clients, such as web crawlers and older clients. Links in this html could default to be links back to the server for other full page requests, and only switch to using ember.js on the client if and when the javascript loads. Applications would have even more reason to make their interactions with the page routable via url and therefore easily linkable and sharable.
Normally when developing websites, you shy away from too much in the javascript because of these usability/SEO concerns and the normal approaches involve writing the same logic on the client and on the server (normally not even in the same language). With javascript on the server, why don't we run the same code on both ends, remove this handicap, and use the benefits to offload processing to the clients when possible but still provide a server-based fallback for the many cases when it is necessary?