2 ms·

I'll take a counter view here. Ember shines best when building very UI rich, complex front end apps. Not apps that need to work on shitty connections or device

I'll take a counter view here. Ember shines best when building very UI rich, complex front end apps. Not apps that need to work on shitty connections or devices. Apps you would use from your office in NY or Toronto. But the sad fact is that there just aren't that many frontend apps out there, relatively speaking. Ember is hard to learn because you need to learn a lot to get things done, and most people building something simple are lazy. By the time their project is a huge mess they're already locked in. Take HN for instance, the tech powering it is dead simple. It doesn't need to be giant frontend app. Ember is a really solid framework that I love that is never going away, but it isn't for everyone and that is ok. Ember devs make a higher salary because they generally need to know more and the apps are more maintainable and generally run by pro dev shops, but it's not for everyone. One thing I think that could really help Ember is a version of Rails or some other backend that required less mucking around to get everything working. It's such a chore to fully follow JSON API v1.1. But relation links and cursor based pagination are great with tools like Ember Data, so it's worth the effort.

berkes 9y ago
> 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 9y ago
  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.

berkes 9y ago

> 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 9y ago
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.