Hacker News Reader

They just recently updated the guide. I haven't read through the whole thing, but it looks much more organized. Also there is a new Router API which is apparently significantly more intuitive.

http://emberjs.com/guides/

Ember data docs are pretty sparse, but once you get up and going, the learning curve is pretty flat. Backbone is pretty easy to get going, but the code complexity gets exponential when you have lots of collections and references that need to be updated.

It's easy to get frustrated with ember & ember-data and just jump ship to backbone, but you'll be paying for it later when your data model expands beyond 5 interconnected models.

The best advice is to tough it out with ember even if the docs are weak and tutorials are sparse.

> <snip> but once you get up and going (...) </snip>

See, that's the problem. How do you get to "up and going" if the docs are sparse?

Just to be clear, this is not meant as a criticism of Ember, just a general observation that I have made time and time again when looking at new projects and reading comments saying things like "yes, X is not documented and hard to get into but once you get up and going it's all roses"

Download all the examples and reverse engineer. That's what I did and I'm glad I did it because I'm loving Ember.

I can tell you that Tomhuda have been working really hard on docs for the last week or so. Ember's getting close to an actual 1.0 release, and docs are a big deal. For instance, they entirely re-wrote the router recently, so if docs had been written before, they'd be out of date anyway.

Not saying it hasn't been bad historically, just that it's getting better and will be good in the future.

I actually just had this same experience this past weekend. Hours spent banging my head against the wall trying to figure out why Ember-Data wasn't working. I don't know what wasn't clicking but I decided to switch to backbone for this project. Literally minutes of work to get backbone going and have my data appear properly.

we use ember at the day job, and historically i've been primarily the backend guy slowly getting familiar with what the front end guys are doing. I agree that the ember-data stuff is pretty thin on docs at the moment. IIRC, it wasn't part of the original stack, but obviously everyone wants a mvc with that persistence layer. So a -1 for that, not sure if it will be a part of ember by the time it reaches 1.0 or not. (oh yeah, it's still technically beta)

But ember shines in other areas that people wont care about until they have to write single page web apps with a high enough complexity that warrants it. The reason we ditched gwt for ember was the 2 way bindings. Not having to write all that stuff(and test it(in every browser))has been a productivity boost, even though we had to plugin our own persistence layer.

Ember Data is a heavy hard-hat area and no wonder you were frustrated. Really, just start with your own data layer and get used to Ember first. Ember has a very Rails-ish philosophy and just like in the Rails world - magic happens (but ya should know how it happens anyways). This blog post is a good intro to how Ember works - http://trek.github.com/ (though routing has come a long way since - http://emberjs.com/guides/routing/defining-your-routes/

> Ember Data is a heavy hard-hat area and no wonder you were frustrated. Really, just start with your own data layer and get used to Ember first

So why is that? This was my big head-scratcher with Ember; surely the access to a data layer is the whole point of these javascript frameworks? I mean all backbone is really is a layer between REST and client-side javascript. I guess i'm missing a whole class of JS applications that don't need access to a server-side data layer, but for me that's the fundamental reason to be looking for a JS framework in the first place. So to come across one so highly regarded which doesn't have it baked in was very jarring.

The idea with Ember-Data and Ember in general is the same as Rails: Conventions give you power. Conventions and a happy path are good. That said, until you _learn_ the happy path, it's harder going.

It's not 'baked in' because Ember is modular: Ember-data has all of that layer in it, so the rest of Ember doesn't have to care. That said, I disagree with your parent: you shouldn't be writing your own data layer.

ah yes, you're right - meant to say that handle the serialize/de-serialize yourself at first to get your feet wet.

Thanks for the direction, I'll definitely check that out. Hopefully they have some of these baked soon, I did like a lot of the other features as advertised.

Ember-Data isn't easy, and I'm sure when your frustration is running high it's easy to just say screw it and jump to backbone, but you'll be paying for it later if your frontend has more than 5 deeply connected models.

A lot of work has been done to make it easier to get started with Ember. You should check out the guides on emberjs.com.

+1 - I've been following the Ember progress and have been blown away with the progress made last year. It's the most mature UI friendly framework for frontend out there. Fwiw, this (slightly outdated router code but a good philosophical intro) post is super useful for diving into Ember - http://trek.github.com/

We use Ember + Rails at work and if we didn't start with an Ember expert contractor we'd have been sunk. Ember is definitely a winding maze of stuff and until there's a "Agile Web Development with Ember 1.0" book, it's still very difficult to just jump in from scratch.

Still, once we've learned Ember we're very happy with it. Backbone is just too small to start any medium/large app, and Ember has a decent community behind it and lots of integrations with Rails.

What function is the Rails component serving? Is it just a REST interface or is it also acting as a separate HTML interface?

We're working on https://github.com/rails-api to make Rails a great backend for APIs, and specifically Ember. Team is mostly Rails Core members and Ember team members.

The hope is to make it awesome for other JS frameworks too, but we mostly build Ember apps ourself, so you start with what you know...

Huge +1 on rails-api. When used in combination with rabl, it's the most formidable Backend solution there is.

We actually think that AMS is significantly better, but I'm glad rabl works well for you. :)

Mostly for the gluing and custom node editing, but also I really like keeping my rabl files (presentation) outside of my models

Totally. And there's a reason AMS isn't part of rails-api proper: we want you to pick the tools you want to use. If rails-api (the gem) doesn't work with RABL in some way, please let me know, that's a bug.

You haven't seen the full power of AMS yet, but I have some exciting things planned. :)

Glad to hear rabl is working well in conjunction with rails-api. Haven't had a chance to try that combination yet, mostly been using rabl alongside Sinatra, Grape and Padrino.

As I said below, if it doesn't, please let us know: I'd consider that a bug.

You can do both, for example, you can use rails for authentication with traditional views and then use ember for the main single page app. I think this is how square does it.

Also you should look into active model serializers for integrating rails with ember. I think it's yehuda Katz' preferred method for Jason serialization from rails to ember.

> I think it's yehuda Katz' preferred method for Jason serialization from rails to ember.

That is true. AMS + Ember-data = 👍 (I'm now maintaining AMS, but Yehuda and Jose Valim originally wrote it for this purpose.)

I experienced the same thing with Ember Data/REST.

"I can't remember what exactly I didn't get working, but I just felt very lost and overwhelmed, and that was spending a couple of days reading around online, looking at the code and examples."

Exactly.

I don't want to feel "lost and overwhelmed" when trying to learn some new product, or having to Google every single thing. It is a wonder anything ever gets done. Seems these things are written by someone in their ivory tower without any forethought to documentation. "Someone else wants to learn it? Not my problem! I developed it, so there! No good documentation for you." That is just lame.

As someone who has sacrificed his last few weekends and holidays writing documentation for my open source projects, I can assure you that that is not my attitude, and the fact you think so is very disappointing.