Always awesome to see another production Ember.js app in the wild.
On a personal note, the team behind Confetti also organizes the NordicJS conference in Stockholm. In addition to running one of the best JS conferences in the world, IMO, they are also some of the nicest people in the community. As a NordicJS attendee, I've been "beta testing" Confetti for some time. It's a great product and I wish the team all the best.
Thanks, Sam. Like all things in technology, there are tradeoffs to make and a cost-benefit analysis that every project will do differently. We spend a lot of time on backwards compatibility in Ember, but my goodness, it's painful.
Recently, the results of the Ember Community Survey were released and the aspect of it I'm most proud of is the number of developers who are using the latest release version. The majority of respondents were on either 1.9 or 1.10, and 1.10 wasn't released until halfway through the survey.
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 ;).
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?
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)
Additionally, progressive enhancement techniques almost always involve server-side rendering, which means you lose the benefits of client-side routing I describe in the post.
The goals of progressive enhancement are wonderful. My complaint has always been that previous techniques hamper developer productivity far too much to be realistic. With FastBoot, I'm hoping we can offer the benefits with far fewer costs.
I think this might be semantic quibbling at this point.
Yes, progressive enhancement and server-side rendered JS are similar. You can see the latter as a new version of the former. But it is implemented in such a way - a novel way - that it definitely deserves a term of its own.
It's not really useful for the conversation to lump it in with the traditional definition of progressive enhancement that's been done for years.
Even middle of the road efforts I tried a few years ago (such as sharing a templating language between client and server even when the implmentation language differs) was fraught with friction compared to this technique.
Most people think this problem has already been solved by being able to render templates on the server, but the problem is much harder than that. For example, I learned on HN yesterday that most server-rendered Flux apps can only handle one request a time, due to the reliance on singletons. You really need an application-wide DI system like Angular/Ember to get this working with multiple requests in parallel.
It's awesome to see you guys embracing server rendering, but it's incorrect to say most server-rendered Flux apps can only render one request at a time. If you're designing an isomorphic architecture, it's certainly a consideration, but I doubt any production apps have this limitation.
A common pattern is to instantiate a new store for every request, to avoid collisions.
The Flux fragmentation makes this hard to talk about. The examples I've seen from Facebook all use global singletons. There are some libraries/implementations that work correctly, but it's hard to know how widely used those are.
I guess the high order bit for me is that developers shouldn't have to worry about stuff like this—picking the "right" implementation of their app architecture. Ideally, everything just works out of the box. The harder it is to do, the less likely people are to do it.
We use Mongo and currently Mongo is the only database with an adapter for the full realtime synced stack. However, Derby itself can be uses without the ShareJS backend, and it is possible to write adapters for different databases. Thanks for the question!