[berkes]

> Not apps that need to work on shitty connections or devices.

Curious, why would you say that? I've only ever dabbled with Ember a little, never built anything production-ready with it. But I did have to maintain an Angular (1) app. And that thing was chatty as hell. I was the backend dev, and developed the REST api that our apps and this Angular bowl-of-spagetti communicated with.

Where ember has, built in, localstorage caching and even some cool REST-sync systems, angular has none of that. The closest I could get was angular-resources, which is a ORM-alike-approach to communicating with a REST backend. Proper HTTP-caching headers, Etag caching and so on, allowed leveraging the browsers-caching to avoid some calls, but Ember has a far neater and cleaner way to talk to such a backend.

This is just an anecdote, but I was pretty convinced that from all the JS-frameworks, ember had the "get data in- and out of a REST backend" solved the nicest, fastest and cleanest.

[3pt14159]

It's more the type of app that you build with Ember. It ends up just being so much more complex and that requires multiple requests. You can't locally store everything, and you often can't do everything on the first request, so if you're on a connection where packet loss is an issue instead of 3 or 4 round trips you end up having 16 or 20. With a shitty device the commutative lag between janky animations (which ember makes easy with libraries like Ember-Concurrency) it just destroys the experience.

Whereas the other frameworks don't make things as app-y as easily so its more like a local template language than an app builder. So people don't go as hog wild.

That plus a larger initial JS file than something slimmed down like React. It kinda adds up even if in theory it shouldn't.