Why we're moving away from Ember.js

Re:Why we're moving away from Ember.js by troygoode on Friday March 22, 2013 @02:10PM (#5424564)

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.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by wycats on Friday March 22, 2013 @03:27PM (#5425059)

> 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).

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by coolsunglasses on Friday March 22, 2013 @04:09PM (#5425346)

>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.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by steveklabnik on Friday March 22, 2013 @04:25PM (#5425449)

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?

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by coolsunglasses on Friday March 22, 2013 @05:45PM (#5425996)

I'm not sure how Ember Data is different beyond providing a smarter interface to collections and models than BackBone.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by steveklabnik on Friday March 22, 2013 @09:26PM (#5426862)

Hence 'not ready yet.'

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by jsg on Friday March 22, 2013 @06:17PM (#5426139)

Have you actually read http://docs.angularjs.org/api/ng.$http or https://github.com/documentcloud/backbone/blob/master/backbo... ?

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by coolsunglasses on Friday March 22, 2013 @06:56PM (#5426307)

Yes, I think we just disagree on how different and special Ember Data is.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by mpowered on Friday March 22, 2013 @05:04PM (#5425745)

> 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.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by troygoode on Friday March 22, 2013 @07:04PM (#5426341)

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.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by mpowered on Monday March 25, 2013 @07:43PM (#5440437)

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.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by steveklabnik on Friday March 22, 2013 @04:20PM (#5425416)

> 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) and states "This is definitely alpha-quality. The basics work, but there are for sure edge cases that are not yet handled."

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by troygoode on Friday March 22, 2013 @07:02PM (#5426330)

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.

[ Parent | on HN ]

Re:Why we're moving away from Ember.js by davedx on Friday March 22, 2013 @03:03PM (#5424915)

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?!

[ Parent | on HN ]