4 ms·

Ember being impressive but not yet ready for prime time seems to be a common refrain on HN these days, and one of the big gaps holding Ember back appears to be

Ember being impressive but not yet ready for prime time seems to be a common refrain on HN these days, and one of the big gaps holding Ember back appears to be Ember.Data. I have no doubt the team is working hard to improve Ember.Data and move it into "ready for prime time" territory, but why move Ember-proper to a "1.0" release without Ember.Data also being ready? Every major competitor to Ember (including its predecessor, SproutCore) has a data layer that does more than pass the buck off to jQuery. Yes, the move to 1.0 locked the non-Ember.Data portions of the API, but it seems short-sighted to believe that that will be enough for most users. The "1.0" is communicating a set of implicit expectations that I suspect the core team didn't intend for it to quite yet. It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready.

davedx 14y ago
Yeah, you have to be very careful with what you assume about version numbers. Node.js is v0.10 which strikes me as overly-cautious version numbering. And Gitlab is... v5?!
wycats 14y ago
> Every major competitor to Ember (including its predecessor, SproutCore) has a data layer that does more than pass the buck off to jQuery SproutCore had a robust data layer, but 2013-era frameworks mostly expose HTTP directly as the abstraction to use, either via $.ajax or a framework-specific HTTP library. Other frameworks are not trying to solve data persistence and loading beyond delegating to HTTP, but Ember's solution isn't ready yet (so we don't get to say that it's a win of using Ember over the competition -- yet).
- coolsunglasses 14y ago
  >Other frameworks are not trying to solve data persistence and loading beyond delegating to HTTP I don't think that's true, given how Backbone and Angular are designed.
  - steveklabnik 14y ago
    I'm not an expert in JS frameworks, but my understanding is that backbone converts 'save this model' to '{PUT,PATCH} /models/:id', and then makes the request. Isn't that just delegating to HTTP?
    - coolsunglasses 14y ago
      I'm not sure how Ember Data is different beyond providing a smarter interface to collections and models than BackBone.
      - steveklabnik 14y ago
        Hence 'not ready yet.'
  - jsg 14y ago
    Have you actually read http://docs.angularjs.org/api/ng.$http http://docs.angularjs.org/api/ng.$http or https://github.com/documentcloud/backbone/blob/master/backbone.js#L1110 https://github.com/documentcloud/backbone/blob/master/backbo... ?
    - coolsunglasses 14y ago
      Yes, I think we just disagree on how different and special Ember Data is.
steveklabnik 14y ago
> It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready. Ember 1.0 was released? Looks like only an rc-1 so far to me. Also, Ember-data is a distinct project from Ember itself, no? It's in a different repo (https://github.com/emberjs/data https://github.com/emberjs/data) and states "This is definitely alpha-quality. The basics work, but there are for sure edge cases that are not yet handled."
- troygoode 14y ago
  Fine, you got me on "release" vs "release candidate." Still, it is clear that the plan is to release Ember as a 1.0 without Ember.Data (it would be very strange to add something of Ember.Data's scope into a release but not have it in the RC). I'm aware that Ember.Data is considered separate. The entire point of my post was that I believe this is a mistake.
mpowered 14y ago
> It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready. I would only agree with that if ember.js were useless without ember-data or a similar data-persistence layer. I don't think it would be wise to delay the release of Ember 1.0 RC simply because ember-data is still in alpha. Not everyone is going to be using ember-data, and releasing ember without it lets them solve the data persistence on their own.
- troygoode 14y ago
  Unfortunately how separate Ember.Data is depends on which documentation you read. In general most of the official documentation assumes you're using Ember.Data. That makes it feel missing, not separate.
  - mpowered 14y ago
    Very true. I don't think the distinction is clear enough that ember-data is a completely different repo, and I think that's definitely a problem.

davedx 14y ago

Yeah, you have to be very careful with what you assume about version numbers. Node.js is v0.10 which strikes me as overly-cautious version numbering. And Gitlab is... v5?!

wycats 14y ago

> Every major competitor to Ember (including its predecessor, SproutCore) has a data layer that does more than pass the buck off to jQuery SproutCore had a robust data layer, but 2013-era frameworks mostly expose HTTP directly as the abstraction to use, either via $.ajax or a framework-specific HTTP library. Other frameworks are not trying to solve data persistence and loading beyond delegating to HTTP, but Ember's solution isn't ready yet (so we don't get to say that it's a win of using Ember over the competition -- yet).

coolsunglasses 14y ago
>Other frameworks are not trying to solve data persistence and loading beyond delegating to HTTP I don't think that's true, given how Backbone and Angular are designed.
- steveklabnik 14y ago
  I'm not an expert in JS frameworks, but my understanding is that backbone converts 'save this model' to '{PUT,PATCH} /models/:id', and then makes the request. Isn't that just delegating to HTTP?
  - coolsunglasses 14y ago
    I'm not sure how Ember Data is different beyond providing a smarter interface to collections and models than BackBone.
    - steveklabnik 14y ago
      Hence 'not ready yet.'
- jsg 14y ago
  Have you actually read http://docs.angularjs.org/api/ng.$http http://docs.angularjs.org/api/ng.$http or https://github.com/documentcloud/backbone/blob/master/backbone.js#L1110 https://github.com/documentcloud/backbone/blob/master/backbo... ?
  - coolsunglasses 14y ago
    Yes, I think we just disagree on how different and special Ember Data is.

steveklabnik 14y ago

> It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready. Ember 1.0 was released? Looks like only an rc-1 so far to me. Also, Ember-data is a distinct project from Ember itself, no? It's in a different repo (https://github.com/emberjs/data https://github.com/emberjs/data) and states "This is definitely alpha-quality. The basics work, but there are for sure edge cases that are not yet handled."

troygoode 14y ago
Fine, you got me on "release" vs "release candidate." Still, it is clear that the plan is to release Ember as a 1.0 without Ember.Data (it would be very strange to add something of Ember.Data's scope into a release but not have it in the RC). I'm aware that Ember.Data is considered separate. The entire point of my post was that I believe this is a mistake.

mpowered 14y ago

> It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready. I would only agree with that if ember.js were useless without ember-data or a similar data-persistence layer. I don't think it would be wise to delay the release of Ember 1.0 RC simply because ember-data is still in alpha. Not everyone is going to be using ember-data, and releasing ember without it lets them solve the data persistence on their own.

troygoode 14y ago
Unfortunately how separate Ember.Data is depends on which documentation you read. In general most of the official documentation assumes you're using Ember.Data. That makes it feel missing, not separate.
- mpowered 14y ago
  Very true. I don't think the distinction is clear enough that ember-data is a completely different repo, and I think that's definitely a problem.