You gotta love the Orwellian naming on this one. "Ember FastBoot" meaning Ember-we've-been-selling-you-very-slow-booting-for-years-and-now-we're-hoping-to-mitigate-it-slightly-but-it's-still-vaporware.
Meanwhile, the commonsense approach has always been faster and simpler than this model: Use a small JS framework, not a bloated one, and only load the minimal UI and data set that you need to render the initial page at first. Load the rest later. This includes bootstrapping — remembering to put all the data you need to render the page inline as a JSON object in the HTML.
This can often result in less data sent over the wire than a large HTML page with tons of repeated DOM elements. It's also far easier to cache appropriately.
I don't want to get into a big discussion on small libraries vs. big frameworks (your use of the word "bloat" gives away your position here ;).
I would ask readers of this discussion to visit any of the web applications they use on a daily basis, open the developer tools, and look at the size of the JavaScript payload. Whatever libraries or frameworks they're using, the payload size is almost always several hundred kilobytes.
I'd argue that using small libraries is a noble goal, but in practice, you just need several hundred KB of JavaScript to build modern apps. If we're honest with ourselves about it, we can try to do a good job of managing it from the beginning. Otherwise you just end up with an ad hoc mess.
The other point I tried to make here is that, yes, of course, you can do all of this by hand. But in practice, most teams are so under the gun to ship features that they don't do it. If we can make great boot performance as easy as installing an npm package, why not?
Lastly, regarding the vaporware claim: we've got a very alpha version up on GitHub already. I invite Ember users to play around with it and give us feedback: https://github.com/tildeio/ember-cli-fastboot.
I'd like to stand up and be counted as saying that both
1. Ember absolutely isn't to my taste and I've successfully avoided it so far and intend to continue doing so in future
2. The work you're doing is really cool and I'm looking forward to seeing it completed, both for the benefit of my friends with different tastes who're happily using ember and for the benefit of everybody else in that it provides a worked example of an awesome idea.
(and people who dislike it just because they dislike ember might, possibly, need to remember that trailblazing is important for new ideas)
Meanwhile, the commonsense approach has always been faster and simpler than this model: Use a small JS framework, not a bloated one, and only load the minimal UI and data set that you need to render the initial page at first. Load the rest later. This includes bootstrapping — remembering to put all the data you need to render the page inline as a JSON object in the HTML.
This can often result in less data sent over the wire than a large HTML page with tons of repeated DOM elements. It's also far easier to cache appropriately.