Is Ember really the right path forward? Or simply a stepping stone to a better (yet to be discovered) solution?
Specifically, I remember first picking up Rails and how productive I could be in that environment. I haven't felt the same happen with Ember. Instead it continues to feel like more work, as I have to build a client side domain model, as well as a server side model, and often have to think carefully where the logic should be placed.
Don't get me wrong, Ember is a step in the right direction, and there is a lot to love about it, but at the same time it feels like a local maximum and that there is a better paradigm to be discovered (Meteor perhaps?)
So, for those past the initial Ember hurdles, is Ember fulfilling its promises for you with your projects? Do you disagree with me and see Ember as the right long term approach for rich web applications?
Having reflected on my own question for the past 20 minutes I'll add the following.
For decades programming languages struggled with how to persist object state. We built custom file formats, tried to serialize object graphs, built ORMs to map to SQL databases, but it took us three generations or so to get ORMs right.
Today's struggle is how to program a distributed application. First we built the server to render dumb html, then got smarter and added some glue like JQuery to the client, now we are onto full fledged client side frameworks. But we haven't fundamentally solved the productivity challenge to generate a rich client experience that leverages the work done on the server. I can't help to think that a unified programming model between the server and client frameworks could become a significant step forward.
I'm excited to see where concepts from isomorphic JS and stuff like browserfy will end up. Obvious stuff aside, imagine what you could do with a fully-baked unified model and a bit of P2P glue...
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.
We began rebuilding Intercom with Ember.js in April this year. We now have 12 engineers working with Ember and both the pace of development and the quality of our output has been amazing. Ember bills itself as 'A Framework for creating ambitious applications' and we've found this to be very true. We upgrade to the latest point release every six weeks or so and this process has been painless.
This isn't exactly the question you asked, but I recently accepted that client-side applications are the future and spent some time with Ember (which as a Rails developer I wanted to like) and AngularJS (about which I was skeptical because it looked like nothing I'd seen before).
After two weeks in each, only AngularJS was paying off (I got architectural and productivity benefits in return for the time I spent learning all those framework things which seem arbitrary at first) so I stopped looking at Ember and haven't looked back.
Same boat as you. I wanted to like Ember; everything on paper looked great. But with Angular, things just clicked and have allowed me to be more productive than ever.
I would advise both of you to give Ember another chance!
I like to think of things as lying a spectrum: On one end, you have completely hand-rolled framework-less JavaScript. This requires no learning curve whatsoever, but things may get slow and messy as time progresses and you miss out on the cumulative benefits of a framework. At the other end of the spectrum is something like Ember, which takes a while to learn is is just plain overkill for small projects, but which for big projects starts to pay dividends in the long run.
I'm not an Ember dev (I generally can't justify a clean slate project) but I do have opinions on the web development landscape:
The primary source of incidental complexity in frontend development is synchronizing state. The two main places that's happened is synchronizing state between the model and the server and between the DOM and the model. You can see this in the whole history of web development: cookies, sessions, continuations (/wave Seaside), the shift client side (not having to sync viewmodel state, just model state), the MVC shift (restricts where you state interacts), componentization (ditto).
I believe the vDOM/diffing approach is the end of the line in the model->DOM chain. The only place I've found where it doesn't work cleanly is when the output has to be looped back into the model (Rich Text Editor and DnD layout builder) and even that is workable. Otherwise the abstraction has not leaked and reasoning about component behavior has remained local to the component (it's possible to screw this up but that's not the fault of the approach). Once the view layer is written, data goes in, DOM is in the correct state.
Server synchronization remains a problem. The current approaches like Meteor/Derby/Firebase aren't unreasonable but they're rooted in the same place-oriented temporal logic as two way data binding. I don't know what the solution is here. The most promising lead I've run across is Convergent/Commutative Replicated Data Types (CRDTs) from the distributed systems researchers.
In the shorter term, I expect CSP (go channels) to gain acceptance as a replacement for callbacks/promises. It's reasonable to implement the model in javascript on top of generators and is roughly as powerful as functional reactive (FRP) approaches but more accessible to non-functional programmers. There are other efforts like the js streams effort so this might not be the answer but I do expect the community to stumble into a stronger async model than promise chaining.
I'm not particularly bullish on Web Components. Having scoped CSS will be very nice but the rest is focused on problems I don't see as important. I believe the core problem with widgets on the web is customization. There's a lot of web components material on encapsulation but I haven't seen a good explanation of how I can tweak the classList on a node in the shadow DOM for a use case the author didn't anticipate. I've used widget systems (netWindows, Dojo, Ext, YUI, Sproutcore) and have re-implemented many components for this and similarly minor reasons. Encapsulation by itself doesn't do a whole lot for this, I've implemented drop down combo boxes a dozen times. The x-tags/polymer interoperation demos are neat and I think that's the goal but the parochial nature of js libs means it's not something I'd really like to put into one of my projects. Smart people work on this effort so I feel like I'm missing something or not the target audience.
I feel the web components hype in particular to be pretty bizarre, though I feel it's died down recently. Too often the current generation of web people refuse to acknowledge how much has come before as far as Dojo/YUI etc.
What use is a component when every design wants it to look different? Consider the effort it would take to make the native chrome [type=date] datepicker styled however your site desires. That's a relatively low-controversy component compared to tab selectors, pill selectors, who knows what. At some point, it feels better to just write your own and have full control over the style and the lifecycle.
> What use is a component when every design wants it to look different?
You can do a lot with CSS, particularly if the component's CSS has a clean divide between structure and appearance. It's pretty common to want a component to do everything but that one thing, to trigger an event here, to need a wrapper div around the search results, etc. The problem is that everybody's just one thing is different and trying to accommodate them all gets you YUI2.
Re-implementing things winds up being the easiest route but I don't want to re-implement things. Building a business analytics or admin CRUD screen does not fill me with joy. I've been thinking about this problem for years. I really want to solve the problem, at least for my own use, so that I can slap boring stuff together without backing myself into a corner. The dream is to be able to slap everything together then customize and not have it suck.
My best attempts thus far have been in React where I can build override points into my components by having them take additional classes and optional subcomponents. It works (hoorah for composition) but the problem is in describing the input data and events so that you don't need to know the internal implementations of everything. I think the solution there is something along the lines of go interfaces or clojure's protocols and that there's a similar separation of concerns available in sass for the CSS side of things. I poke at it every so often but get distracted by other things.
Specifically, I remember first picking up Rails and how productive I could be in that environment. I haven't felt the same happen with Ember. Instead it continues to feel like more work, as I have to build a client side domain model, as well as a server side model, and often have to think carefully where the logic should be placed.
Don't get me wrong, Ember is a step in the right direction, and there is a lot to love about it, but at the same time it feels like a local maximum and that there is a better paradigm to be discovered (Meteor perhaps?)
So, for those past the initial Ember hurdles, is Ember fulfilling its promises for you with your projects? Do you disagree with me and see Ember as the right long term approach for rich web applications?