Count me in, too.
As a matter of fact, I’ve just hacked together small proof of concept. With the upcoming Htmlbars library and its Ember integration, it becomes way easier to provide fast boot kind of thing.
For me, the most important goal here is to be able to send plain html from the server, which would be then progressively enhanced by Ember. I.e. Ember would construct view around the existing DOM elements, not replacing them. That of course is extremely tricky and introduces truckload of corner cases and other problems.
Having such ability, would simplify SEO a lot, at least in some cases. In case you just want to present tons of textual data, you can embed it to HTML and send out, no matter who is asking. Google bot will get it and see the content without running JS or any other tricks. Real users, though, will see HTML being displayed immediately, then (hopefully short) moment later Ember will kick in and enhance the HTML with behaviour. Well, at least this is what I’m after.
In such scenario, it is simply not important how that HTML was generated server-side. Sure, having Ember there would be extremely convenient. At least for those with ‘compatible’ technology. But, if you’re using java-powered servers, PHP, ASP.NET, Perl, CGI, or whatever, server-side Ember will not be convenient anyway.
Regardless whether incoming HTML was server-side generated with Ember, or by any other mean, there is always a possibility that browser-side templates will not match it. So far I’m not trying to address this problem. However, some kind of validation could be done, at a performance cost.
Assuming that incoming HTML is proper, though, it gives interesting possibility - to actually populate model’s properties from the incoming text. I.e. if you have template like:
<p>{{item.name}}</p>
and the incoming HTML is:
<p>Foo</p>
you could actually try to reduce duplication over the wire, so not send that property to the browser, and let the browser figure out item.name from the HTML. For me this is quite optional thing, but worth considering. Unfortunately it opens yet another can of worms. What if the property is not string based? Integer, for example? Or, worse, some more complicated value?
Regardless of whether you’re reading HTML to populate your models or not, progressive enhancement (Fast Boot) also brings other problems to the table - helpers. If your template contains {{#view}}, {{each}} or anything else, even simple {{#if}}, non-trivial logic would need to be added to handle this. I think that the problem is next to unsolvable, at least in few cases. If we want to have stable production support for fast boot, some simplification need to be done, probably. Like ‘only simple text properties are supported’ or something like that. One of the simpler solutions would be just to not include those bits of content in the HTML, but allow Ember to inject them in runtime, just as it does now. E.g. with such template:
<p>Item: {{item.name}}</p>
<p>{{view App.ItemView itemBinding=item}}</p>
and such HTML being sent from server:
<p>Foo</p>
<p>Please wait, loading...</p>
Ember could just populate second
with correct view, replacing its content (i.e. removing ‘Please wait, loading’ part). Sure, googlebot wont see it, users will see jump, but still that might be the right compromise between sanity and usefulness.
So, my proof of concept. First of all, I’ve based on the temporary @ebryn’s code with partial htmlbars draft integration. He marked this code as ‘do not use anywhere’, and he was right. Some hacks are there, waiting for fixes, as well as many unfinished parts. I decided to go on my own and add a layer of my own hacks on top of his, so the result isn’t too pretty. But it shows that the concept can work. Clean, stable, integration with HTMLBars will be necessary first to reach production phase. Then, we can think about adding fastboot in cleaner way, too.
My starting idea was very simple. The code was actually <15 lines. You can see the core part here, with some Ember test to check it out here. I’m intentionally using ‘hack’ word few times per sentence, because I mean it. Do not try this at home 
The way how Htmlbars is working is quite simple. When template is compiled, library analyzes its DOM structure, how many elements are there, where mustache helpers are injected etc. When template is rendering, first the static content is created (via a series of document.createElement and related calls). Then, dynamic content is added to that, with listeners set up properly to handle updates (process called hydration). And, there is also interesting optimalization - the static content is created only once, during first render. Then, for each render (including first one), clone of that is done, and the clone is hydrated. That is very nice in term of speed, since closing some master copy is way faster than building it from scratch. And also this is a cornerstone of my PoC - what if the master copy would be actually taken from DOM, from the HTML document incoming from server? My test shows that it can theoretically work.
You need even more dirty tricks, however. Namely, in templates in Ember are nicely isolated from runtime DOM. They can render completely offline, with no depedencies. My approach inherently violates a number of rules and bounds those clean templates into document’s DOM. This is the price, though, if you do want to preserve DOM fragment, template need to be aware of it.
My hacky PoC is still full of bugs, as well. E.g. it doesn’t handle corner cases. The way how Htmlbars works with document fragment ranges is tricky, too. Handlebars were injecting metamorph scripts everywhere, then just cleared content between them. Htmlbars is not doing that (which results in significant speed increase), but it still need to have range between 2 points. So, if you have template like this:
a{{foo}}b
and after rendering the template you remove ‘b’ part (e.g. by jQuery), Htmlbars will fail to update foo later on. That bad side effect is amplified by my hack, so better solution would need to be created, probably.
I’ve modified the Htmlbars code directly, but I think that in the end solution the best choice will be to have that part pluginnable. I.e. Htmlbars could not be aware about fast boot at all, but if it would allow plugins to modify its template mechanisms, I’d be just happy to include htmlbars-fastboot-plugin.js, just like 0.1% of other users, who need that part.
If the production-quality fastboot implementation will require some deeper changes to Htmlbars, extracting that to plugin might not be feasible/easy, however.
So, what do you think?
(cf https://github.com/emberjs/ember.js/issues/563#issuecomment-6218483)