I've been using both Ember and Ember Data for almost two years now for pretty much everything (mostly contract work and personal projects).
Ember had a very high learning curve when I first started using it. Admittedly, I immediately jumped into a huge project with it, which is worse for learning than starting with lots of small ones. Still, it took me months before I felt truly productive. Hopefully things have improved since then, but I'd say it was worth it, regardless. I can't imagine writing a substantial Javascript-heavy app without it or something like it. I did that several times in the past, and I always ended up having to basically construct my own ad hoc framework, which takes a ton of time and maintenance.
Comparatively, Ember has its own built-in conventions for routing, views, models, etc, similar to Rails. Once you know how it all works, it's fairly obvious what "the right approach" is to using these features. The result is that your code is more easily navigable and maintainable, both by yourself and by other Ember developers seeing your code for the first time.
As for the back-end, the last few projects I've worked on with Ember, I've spent very little time worrying about it. One has a Rails back-end that basically serves a REST API for the Ember app. After I finished building the REST API, I almost never had to touch the back-end again. The other two projects use Firebase and the Dropbox Datastore Sync API, both of which store data and feed it into the Ember app in real time in a Meteor-esque fashion. And again here, I spend 99% of my time working with front-end code.
So, to answer your question, yes, Ember is fulfilling its promises for me, and I think it's likely to be the right long-term approach. I haven't used Meteor, yet, but it's hard for me to see it being vastly superior to something like Ember+Firebase. And if it doesn't put a lot of thought into handling things like views (and views within views (and views within views within views)), then I can't see it being much of a step forward for writing front-end code.
I'm building apps. The projects I'm currently working on are a heavy-duty collaborative task manager (think Asana), a task manager + email client (think Mailbox, but with tasks and for the web instead of mobile), and a note-taking app (think Evernote).
Before that, I worked on other apps using Ember, as well as one or two more "website-like" projects that are mostly static, but had a few interactive widgets. FWIW I think Ember was overkill for those, and I would've been better off just going with normal HTML/CSS delivered from the server and Backbone for the widgets.
Ember bills itself as "a framework for creating ambitious web applications", and I agree with that use-case completely.
Ember had a very high learning curve when I first started using it. Admittedly, I immediately jumped into a huge project with it, which is worse for learning than starting with lots of small ones. Still, it took me months before I felt truly productive. Hopefully things have improved since then, but I'd say it was worth it, regardless. I can't imagine writing a substantial Javascript-heavy app without it or something like it. I did that several times in the past, and I always ended up having to basically construct my own ad hoc framework, which takes a ton of time and maintenance.
Comparatively, Ember has its own built-in conventions for routing, views, models, etc, similar to Rails. Once you know how it all works, it's fairly obvious what "the right approach" is to using these features. The result is that your code is more easily navigable and maintainable, both by yourself and by other Ember developers seeing your code for the first time.
As for the back-end, the last few projects I've worked on with Ember, I've spent very little time worrying about it. One has a Rails back-end that basically serves a REST API for the Ember app. After I finished building the REST API, I almost never had to touch the back-end again. The other two projects use Firebase and the Dropbox Datastore Sync API, both of which store data and feed it into the Ember app in real time in a Meteor-esque fashion. And again here, I spend 99% of my time working with front-end code.
So, to answer your question, yes, Ember is fulfilling its promises for me, and I think it's likely to be the right long-term approach. I haven't used Meteor, yet, but it's hard for me to see it being vastly superior to something like Ember+Firebase. And if it doesn't put a lot of thought into handling things like views (and views within views (and views within views within views)), then I can't see it being much of a step forward for writing front-end code.