Here's where I am at with things for Float:
- done a load of stuff with backbone, and it's what we use in production
- played with ember, but nothing too serious. Thinking it might be good for Float, but it's got a steep learning curve initially, so it may never happen.
Having read http://trek.github.com and worked through the examples, and compared it to what I've done in backbone. My thoughts are:
-
it's not a totally fair comparison, backbone is very small, and you could use it alongside existing code quite easily. Ember is huge, and feels like more of an all or nothing solution. You could pick and choose bits of backbone, and be okay. But with ember it feels like, do it this way, or don't do it.
-
that said, it does mean you end up writing a lot of boilerplate code in BB than you would in ember. Things like (https://github.com/marionettejs/backbone.marionette) bring backbone closer to an ember like level of functionality though
-
ember's routing solution looks very slick (that trek document talks about it a lot). They treat your application as a state machine which you can dive in and out of via urls. If you have a very complex UI, this could be pretty powerful. (A big part of why I'm thinking about it for float).
-
If you are working with lots of model objects, that maybe have computed properties, and you want the whole UI to update when things change, ember has you covered. Backbone doesn't really have any data-binding built in. You can add it, with things like Backbone.ModelBinder, but my impression of ember is that once you figure it out, it will just work.
-
I would completely agree with trek's statement that "ember apps start at a complexity level of 4/10 but never get above 6/10, while backbone starts at 1/10 and quickly tend to (8/9/10)/10". This makes backbone much easier to start with but there's definitely a lot of space in backbone to get yourself in a muddle.
-
Similar to above, but I often feel like with backbone that there's a lot of ways I could achieve something (that's because BB is really a little library not a framework).
-
Ember is really hard to get going with. Like really hard. It's mind bending, the docs are shit (but getting better I believe), ember.data (which you use to get data via a json api) isn't really production ready (backbone has json syncing built in). But once you get your head around it, it starts to get interesting. Backbone on the other hand seems almost obvious, and there's so little code you can just dive into the annotated source and understand what's going on.
-
If you are refactoring existing code, I feel like with backbone, you could drop the library in, and start refactoring things a chunk at a time quite happily. And have confidence in it. With ember I almost guarantee you would end up starting over from scratch.
-
If I was building something like Float, or a 37 signals product, which is basically a lot of form editing, and complex views of aggregated data, I would take a good look at ember. But if I was doing something more fancy, maybe with maps, or lots of DOM manipulation for a fancy UI (which I am wondering if moovweb is more like) I think backbone's flexibility would be a much better starting point.