I used to recommend Batman.js for an amazing API. But they sorta follow a six month release schedule. It's too slow for my taste. Move fast, break often.
In their case it's move slow, stay broken. I like Batman.js but I feel like it's really falling into the shadow because of slow release cycles.
PRs take 3 months to get accepted, and etc.
Embers take of ArrayController and ObjectController fits my iOS code design pattern with controllers for index/collection and controllers for member/detail.
I'd just like to echo your comments about Batman.js. It'd be nice to see Shopify put a little more man power behind that framework. Harry does the best he can do but he's only one person.
Depends on what you want. Those are 2 of the more "opinionated" frameworks, in that they have a lot of fairly-strict rules that must be followed if you want things to go smoothly.
On the other hand, there's frameworks like Backbone (and derivatives, like Marionette), which are much less opinionated; fewer decisions are made for you, giving you more flexibility to do what you wish, how you wish.
The trade-offs are that for the lower-level frameworks (like Backbone), you'll probably end up writing more code (both custom and boilerplate), and there'll be less magic happening within the blackbox that is the framework. Some like this, some don't, but ultimately it depends on the task at-hand and your own stylistic preferences.
Ember.js is incredible. But, I highly recommend looking into the non-opinionated options out there as well.
I started with Ember.js building my app, but realized it exceeded the needs of the project and strongly imposed the design of the application. Since I had the time to invest up front, I switched to using non-opinionated libraries:
Ember team, release it already. Its going to be fine. if there any bugs left, you can follow it up with minor bug fix release. More Importantly, not having a stable release does hurt the adoption of framework. Just Saying
Agreed - although Ember Data is working well for me, I've found the lack of documentation to be a productivity sink. Too often, I have to get into the code to find out how things work (even to get a list of possible values for DS.attr(), for example).
I'd love to know where I can contribute to the docs, so I can help update them as I learn things.
@wycats has already mentioned [0] that Ember Data is supposed to hit RC status at the same time Ember.js launches, which should be by the end of this month (August 2013).
The level of commitment from the Ember maintainers is very reassuring. Especially when trying to pick a client-side framework.
However, coming from RoR, there's a bit of a learning curve due to the lack of a prescribed file structure or server-side setup. So, I've been hacking some components together as a full-stack template for Ember and Node with some nice features like Hapi API, scaffolding & Brunch build tools. Shameless plug: http://github.com/cpursley/ember-wings
Every time a new Ember RC is released I read a little more about it, and I have to say that this time I'm actually considering giving it a go.
This probably seems a little weird - why wouldn't I want to give it a go? I guess it's because I've been using AngularJS for several months now and learning something as opinionated and complex as Ember is a pretty hefty investment in terms of time and effort.
seivan mentioned ObjectController and ArrayController, which I think are really cool. Does anybody else know of any other features that might whet my appetite and convince me to jump on the Ember train?
Not sure if you find it cool because you got an iOS development background but http://epf.io that works with Ember (sorta like a replacement for Ember-data) shares the same semantics that Core Data does with its Context Manager (scratchpad).
You can have child contexts and merge to the parent and so on.
Check it out.
Anyone using this in production? I've been looking for a stable alternative to Ember Data for a while that helps you with things like rolling back when the server returns an error response.
29 comments
[ 83.1 ms ] story [ 881 ms ] threadI think the real story here is how good these guys are getting at avoiding the voting ring detector.
In their case it's move slow, stay broken. I like Batman.js but I feel like it's really falling into the shadow because of slow release cycles. PRs take 3 months to get accepted, and etc.
Embers take of ArrayController and ObjectController fits my iOS code design pattern with controllers for index/collection and controllers for member/detail.
On the other hand, there's frameworks like Backbone (and derivatives, like Marionette), which are much less opinionated; fewer decisions are made for you, giving you more flexibility to do what you wish, how you wish.
The trade-offs are that for the lower-level frameworks (like Backbone), you'll probably end up writing more code (both custom and boilerplate), and there'll be less magic happening within the blackbox that is the framework. Some like this, some don't, but ultimately it depends on the task at-hand and your own stylistic preferences.
I started with Ember.js building my app, but realized it exceeded the needs of the project and strongly imposed the design of the application. Since I had the time to invest up front, I switched to using non-opinionated libraries:
- Rivets.js for DOM data binding: http://rivetsjs.com/
- Director for URL routing: https://github.com/flatiron/director (also see Crossroads.js)
- Stapes.js for observable objects: http://hay.github.io/stapes/ (Stapes provided the foundation for my controllers and models)
I was able to borrow lots of design concepts I learned from Ember when re-implementing, and the total JS file size ended up being about half.
Ember team, release it already. Its going to be fine. if there any bugs left, you can follow it up with minor bug fix release. More Importantly, not having a stable release does hurt the adoption of framework. Just Saying
I've also seen some tweets to suggest that ember-data is getting a lot of love this month.
I'd love to know where I can contribute to the docs, so I can help update them as I learn things.
[0]: http://discuss.emberjs.com/t/future-planning-roadmap-of-embe...
However, coming from RoR, there's a bit of a learning curve due to the lack of a prescribed file structure or server-side setup. So, I've been hacking some components together as a full-stack template for Ember and Node with some nice features like Hapi API, scaffolding & Brunch build tools. Shameless plug: http://github.com/cpursley/ember-wings
I really enjoy using brunch for web front-end application development.
I suggest using Bower to manage dependencies or (ember|ember-data|handlebars)-source gems if you're using Ruby.
This probably seems a little weird - why wouldn't I want to give it a go? I guess it's because I've been using AngularJS for several months now and learning something as opinionated and complex as Ember is a pretty hefty investment in terms of time and effort.
seivan mentioned ObjectController and ArrayController, which I think are really cool. Does anybody else know of any other features that might whet my appetite and convince me to jump on the Ember train?
You can have child contexts and merge to the parent and so on. Check it out.