Monday, July 22, 2013

Ember and Ember Data

I've been modding my version of Twitarr and checking to see if it works in Ember.Js.

The killer feature in Ember is the router, although the integration with templates (and being able to break your UI into pieces) is a close second in the feature race. As much as I enjoy working with KnockoutJS, it doesn't implicitly have those features. Sure, you could integrate a template engine such as Mustache and use some patterns to break up your javascript, but why do all that work when someone has already built the framework for you.

I've had two basic problems with Ember so far. First is the documentation. It's bad. The Ember team acknowledges how bad it is, but it's still just... bad. It doesn't help that MVC used for webapps bears no resemblance to MVC for client-side code. (Technically the MVC pattern used in Ember is closer to the original ideal)

But it is workable. And when it works, it's honestly amazing. I spent the money on the tutorial from PeepCode - most of the information I had already gleaned by working the Ember tutorial, but there were some things that the Peep guys clarified. It's a good tutorial if you're just starting in Ember.

The second problem is Ember Data. The Ember tutorial as well as the PeepCode tutorial will lead you to use Ember Data, and it is officially Not Done Yet. It also has some serious logistical problems in my mind. One pattern I often use is to have users input data into a form, then send that data to the server to be enriched and sent back. Ember Data has validation, but that's a simple binary save / no save. There's no simple way (that I've found) to be able to modify a record on the server side and update that data back to the client.

It's particularly frustrating in a microblog where I want to timestamp the post server side and add the username server side (I suppose I could check that the username for a post matches the session, but why? - then I'd have to write code to close a security hole that I don't need to open). Rule number one of webapps is to never trust data from the client, and validation doesn't always fit the bill.

Then there's refreshing the data, and having multiple arrays containing the same model type but with different parameters - none of it is really enabled with Ember Data. I just couldn't find simple ways of solving the problems I was running into.

Then I ran into this post by Robin Ward which talks about kicking Ember Data to the curb. And the heavens opened and the light showed down. I had looked through the Discourse github and had seen that they weren't using Ember Data, but it helped to have it laid out in black and white.

(Also a great post by Robin is this one that compares Ember and Angular)

So, yeah. Getting rid of Ember Data removes 99% of the roadblocks I'm running into. I assume that the Ember team is basing their documentation on Ember Data to be future-compatible, but I wonder if they're hurting overall adoption. I know that my frustration level was getting to the point where I was questioning Ember as a choice.