51–60 of 66 posts
Balance the front end and back end application development people!
It seems like Ember Data (and documentation, which is an easy problem to solve) is currently the only achilles heel of the whole Ember. But PLEASE don't judge Ember.js based on a pre-alpha version of an add-on library. There is no sense in that. Ember Data will receive its glory once it's done. Anybody who's every implemented a data persistence layer can tell you that it's not a trivial problem to solve.
Conclusion: Ember.js IS awesome. I love it. A lot of people love it. If you don't like it, then fine. Don't hate on it for no reason. I don't like cauliflower (I hate it), but I don't hate on people who eat it. I admire that they want to be healthy.
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 prede…
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.
Earlier quoted context omitted.
>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.
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?
Earlier quoted context omitted.
> 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 s…
>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.
I wish there was more information about "where" they're going now. They imply that it's not Ember that's broken rather Ember isn't done and the problems are hard that Ember is trying to solve. So I'd ask - why not stay with Ember and help solve the hard problems? Or did you find another technology that "solved" it?
In the meantime, we're just keeping it simple and making magic with D3 and plain jQuery. We pushed all of the CRUD back to Rails, which is probably where it should have been in the first place.
Regardless, it was a great learning experience. I still highly recommend giving Ember a shot on something that's not on a tight deadline to get deployed to production.
Earlier quoted context omitted.
>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.
Have you actually read http://docs.angularjs.org/api/ng.$http or https://github.com/documentcloud/backbone/blob/master/backbo... ?
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 prede…
> 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."
I'm aware that Ember.Data is considered separate. The entire point of my post was that I believe this is a mistake.
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 prede…
> 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…
Earlier quoted context omitted.
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?
I'm not sure how Ember Data is different beyond providing a smarter interface to collections and models than BackBone.