7 ms·

I come from Backbonejs background with which I have worked for about 1.5 years. So I feel quite comfortable with it. I decided to try Emberjs - not for any oth

I come from Backbonejs background with which I have worked for about 1.5 years. So I feel quite comfortable with it. I decided to try Emberjs - not for any other reason than trying to pick up something else and see how other JS framework approaches. I gave full two-days worth of time into it. Initially I thought - "How different can it get?" Plus, I believe even if it's very foreign I'll just keep reading, googling, stackoverflowin', youtube-tutorialin' to get my head around. I gave up though. Here's my hopefully constructive rant, though my views are probably not as deep as the OP's. * Many of the posts on the net are outdated. I followed a few tutorials here and there, and then things didn't work, so I asked on Stackoverflow, then the answer I got was "Dude, your code is outdated". Sure this is probably similar thing for other frameworks - but I'm just sayin' * Models - So there is Ember Object, which you can use as models, but you can also use Ember-data.js which is more "glorified" data. Documentation wasn't clear on the difference. Plus, Ember-data.js was quite hard to get started with. It didn't work well with other versions of Emberjs. I really had to dig in to find the right one to start off with. I ended up cloning a github repo of a tutorial that worked, because nothing else did. * Documentation on "convention over configuration" - OK, so convention over conf. is fine. But the official documentation and many of the tutorials didn't explain what all the conventions there were. I went through a tutorial app, which only had Controller, but things just "worked", because the Emberjs builds all other things for you. Well I didn't know that! THE BEST INTRO EMBERJS VIDEO I found was this. http://toranbillups.com/blog/ http://toranbillups.com/blog/ It finally made sense in the end for me. * But in the end, among all other things I wanted to do, I gave up, because the frustration was mounting up. I guess I can still persist through it. But I just finished AngularJS tutorial demo and in 2 hours, it makes sense to me.

rxcfc 14y ago
The Ember teams has been planning for a sweep of all outdated information about Ember. We'll be updating SO questions and asking blog authors to add a disclaimer. Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the response. We probably do need better documentation in this area to make this clear. That said, it's not fair to count Ember Data as a point against Ember since no other framework has anything at all similar in scope. Our overview documentation is lacking. This is something that we're actively working on improving. The hardest part for new developers coming to Ember is that the paradigms are very different than what they're used to. We believe that the paradigms are the correct ones, but we need to do a better job explaining them.
- bengillies 14y ago
  Without meaning to offend, I'm afraid I have to take issue with your points about Ember-Data. Yes it's optional, and yes you can use jQuery.ajax or whatever, but in reality, it's not quite that simple. The official guides in Ember default to assuming you're using Ember-Data (though they do at least mention it explicitly). This despite Ember-Data being far from production ready (as stated on the Github page) and far too slow for dealing with large quantities of data. At the same time, the conventions that are found in Ember-Data appear to be built in to core Ember (it says as much in the guides). As far as Ember-Data not counting against Ember - it may be larger in scope than other client side data libraries (or the M part of other MVC frameworks or whatever) but the fact is that they are most definitely comparable, as it's the way that Ember gets stuff off the server, and saves it back to the server. Without Ember-Data, Ember has no built in way of doing that, which counts against it. With Ember-Data, well, it's not really ready yet, which also counts against it.
  - rxcfc 14y ago
    Ember is built to work with Ember Data out of the box, but it's trivial to make your own methods that fit with the conventions. I assume you're referring to the default `find` support in the router. All that Ember does is attempt to infer a class name and call `find(id)` on it if the `find` method exists. You can implement this method however you want, or even change your routes to call an entirely different method. I also highly recommend watching one of the follow talks about Ember Data: http://www.youtube.com/watch?v=_6yMxU-_ARs http://www.youtube.com/watch?v=_6yMxU-_ARs or http://www.youtube.com/watch?v=V8nnE948zxk http://www.youtube.com/watch?v=V8nnE948zxk. Both talks make it very clear that Ember Data is not at all comparable to what is offerred by other frameworks.
    - bengillies 14y ago
      I totally get that it's different to what's in other frameworks (the router is similarly different), it's just that, for the most part, on the surface, it pretty much serves the same purpose (other than some relationship stuff that half works). That is, it's the same the same part of the framework, just with extra features. Oh, and with a whole load of undocumented coventions in it. Btw, is there a diagram or something that shows how it's put together internally (I'm pretty comfortable with how to use it from an API perspective, but find myself having to dive into the source code fairly regularly)?

rxcfc 14y ago

The Ember teams has been planning for a sweep of all outdated information about Ember. We'll be updating SO questions and asking blog authors to add a disclaimer. Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the response. We probably do need better documentation in this area to make this clear. That said, it's not fair to count Ember Data as a point against Ember since no other framework has anything at all similar in scope. Our overview documentation is lacking. This is something that we're actively working on improving. The hardest part for new developers coming to Ember is that the paradigms are very different than what they're used to. We believe that the paradigms are the correct ones, but we need to do a better job explaining them.

bengillies 14y ago
Without meaning to offend, I'm afraid I have to take issue with your points about Ember-Data. Yes it's optional, and yes you can use jQuery.ajax or whatever, but in reality, it's not quite that simple. The official guides in Ember default to assuming you're using Ember-Data (though they do at least mention it explicitly). This despite Ember-Data being far from production ready (as stated on the Github page) and far too slow for dealing with large quantities of data. At the same time, the conventions that are found in Ember-Data appear to be built in to core Ember (it says as much in the guides). As far as Ember-Data not counting against Ember - it may be larger in scope than other client side data libraries (or the M part of other MVC frameworks or whatever) but the fact is that they are most definitely comparable, as it's the way that Ember gets stuff off the server, and saves it back to the server. Without Ember-Data, Ember has no built in way of doing that, which counts against it. With Ember-Data, well, it's not really ready yet, which also counts against it.
- rxcfc 14y ago
  Ember is built to work with Ember Data out of the box, but it's trivial to make your own methods that fit with the conventions. I assume you're referring to the default `find` support in the router. All that Ember does is attempt to infer a class name and call `find(id)` on it if the `find` method exists. You can implement this method however you want, or even change your routes to call an entirely different method. I also highly recommend watching one of the follow talks about Ember Data: http://www.youtube.com/watch?v=_6yMxU-_ARs http://www.youtube.com/watch?v=_6yMxU-_ARs or http://www.youtube.com/watch?v=V8nnE948zxk http://www.youtube.com/watch?v=V8nnE948zxk. Both talks make it very clear that Ember Data is not at all comparable to what is offerred by other frameworks.
  - bengillies 14y ago
    I totally get that it's different to what's in other frameworks (the router is similarly different), it's just that, for the most part, on the surface, it pretty much serves the same purpose (other than some relationship stuff that half works). That is, it's the same the same part of the framework, just with extra features. Oh, and with a whole load of undocumented coventions in it. Btw, is there a diagram or something that shows how it's put together internally (I'm pretty comfortable with how to use it from an API perspective, but find myself having to dive into the source code fairly regularly)?