|
|
|
|
|
|
by Tomdarkness
4827 days ago
|
|
|
I agree with most of this, Ember.js is great. However, I'm not so sure on ember-data. It seems like it has great potential and will eventually turn out to be excellent but currently I've found it to be very frustrating when you actually try and use it. To me ember-data is currently either you use it exactly as we specify and it might work but if you attempt to do anything that even slightly deviates from this then you're pretty much out of luck. Firstly, it has a trivial to challenging barrier of entry depending on your skills/environment; it requires a working ruby environment and the ability to build ember-data from the git repo. Then once you start using ember-data you'll most likely find yourself running in to all sorts of problems that involve you delving into the source code to find out what on earth is going off (no docs). Also I fell in to the trap of assuming that ember-data should do something and trying to figure out what was wrong with my implementation when it turns out it can't actually do that. For example, ember-data does not automatically update hasMany collections when you fetch a model with a corresponding belongsTo. Because of this you have to specify every single id of the related models for your hasMany relationship in the parent model's JSON and good luck trying to hack your way around this by appending models to the hasMany collection yourself. As I said though, it does appear to have promise and to be fair it does not claim to be ready for production. However, I think it is a bit early to be attaching words like "love" to ember-data just yet. Ember.js on the other hand currently seems excellent and when ember-data becomes production ready I think they'll make for a very powerful combo. |
|
|
Here are the specific steps we're taking to address your concerns:
1. Thanks to a pull request from Stanley Stuart[1], we now automatically publish builds of Ember Data[2] every time a new commit is pushed that passes our suite of tests.
2. We have begun documenting Ember Data[3] and, while not exhaustive, what we have now is significantly better than just a little while ago. As with what happened with Ember.js, we take documentation very seriously and you should see the Ember Data documentation improve dramatically over time.
3. As we outlined in a recent blog post[4], we are focused on stabilizing Ember Data and do not have plans for new features at this time. If we made a mistake in the initial API design, it was not providing enough imperative trap doors to use when the declarative APIs were not sufficient. We are working on fixing that.
Thanks to our friends at Addepar, we are able to dedicate several full days per week to Ember Data and you should see the velocity of the project increase significantly. Many observers have noticed the recent flurry of commit activity[5]; this was not an aberration but an indication of what the future holds now that we have daytime hours to dedicate to it.
If you have specific suggestions for how to make Ember Data as approachable as possible, please let me know. Like I said, my focus right now is on eliminating bugs, stabilizing APIs, and making sure new developers don't hit frustrating rough spots.
1: https://github.com/emberjs/data/pull/850
2: https://s3.amazonaws.com/builds.emberjs.com/ember-data-lates...
3: http://emberjs.com/guides/models/
4: http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.ht...
5: https://github.com/emberjs/data/commits/master