I'd like to take a look at some of these perceived drawbacks and offer some counterpoints.
It's often argued that writing a client-side application paired with a backend API is substantially more complex than an equivalent server-rendered application. While that may be true in launching a minimum viable product, any time-to-launch advantages will probably dissipate as your service matures. In his criticism of client-side MVC, Thomas Fuchs claims that "what you end up with is building a layer cake that doesn’t add any value and slows down development."
I've found the opposite to be true: a strongly dilineated architecture benefits applications in the short and long run. By developing your front and back ends simultaneously, you can virtually guarantee that your service will have a useful and robust API, even at v1. And with an API as a firewall between front and back end code you'll gain discipline that will clarify architectural decisions and leave you with very little duplication of functionality across your stack.
Time to Load
What's the answer? Start by delivering your assets as quickly as possible with a CDN. Consider splitting up larger applications into modules that can be progressively loaded as needed. This is possible in Ember, for instance, now that the router supports asynchronous loading of routes.
Primitive Browser Compability
Going further, the W3C's WAI-ARIA spec aims to make dynamic content more accessible to people with disabilities. By adding custom
aria-* attributes to elements, combined with semantic structure, you can provide guidance to improve how content is presented by VoiceOver and other sophisticated screen readers.
Another charge that Thomas Fuchs levels is that "if you use something like Ember (which we didn’t), it’s even worse as all applications using it practically look the same (many people choose using Twitter’s Bootstrap library, for example)".
I'm not sure where this originated, but it is not unlike claiming that all Rails applications look the same. As a frequent user of and contributor to Ember, I can assure Thomas (and everyone else) that Ember applications are in no way tied to a particular style or user experience. Peruse popular Ember apps like Discourse, Yapp, Zendesk, and Square to see for yourself.
I realize that this post may seem a bit defensive, but I think it's important to not let claims go unchecked. I've personally been working with Ember.js for the past 20 months and couldn't be happier with my choice for the applications I've been developing. While some aspects of development have been more challenging, I think the pros far outweigh the cons for many types of applications.
Stay tuned for a post that can help clarify this decision for your application...