More
Contact
Submit
Premium
Well, worth skimming, at least. In response to a blog post on aysnchronous Web UIs by the creator of Spine and, years ago, Juggernaut. (Just as Spine is basically an alternate implementation of Backbone, Juggernaut was basically an alternate implementation of the Comet solution which DHH showed at Canada on Rails in 2006 but did not open source.)
Backbone creator Jeremy Ashkenas made the most worthwhile comment in my opinion:
Nice post. I'd like to briefly respond to the bit about the difference between Spine, which generates pseudo-GUIDs for models created on the client, later overwriting them if the server responds with a real id; and Backbone, which has a "cid" (client ID) for every model regardless of the canonical server ID.
The reason why Backbone provides a persistent client id for the duration of every application session is so that if you need to reference model ids in your generated HTML, you always have something to hang your hat on. If I have '<article data-cid="c530">' ... I can always look up that article, regardless of if the Ajax request to create it on the server has finished or not. With Spine's approach: '<article data-id="D6FD9261-A603-43F7-A1B2-5879E8C7926B">' ... I'm not sure if that id is a real one, or if it's temporary, and can't be used to communicate with the server.
Optimistically (asynchronously, in Alex's terms) doing client-side model logic is tricky enough in the first place, without having to worry about creating an association based off a model's temporary id. I think that having a clear line between a client-only ID and the model's canonical ID is a nice distinction to have.
Favorite links include a Spine on Rails demo video which has some nice convenience advantages over anything I've seen with Backbone (although I think Backbone is the way to go generally) and a set of pros and cons for Backbone which is insightful despite being slightly out of date.
Backbone creator Jeremy Ashkenas made the most worthwhile comment in my opinion:
Nice post. I'd like to briefly respond to the bit about the difference between Spine, which generates pseudo-GUIDs for models created on the client, later overwriting them if the server responds with a real id; and Backbone, which has a "cid" (client ID) for every model regardless of the canonical server ID.
The reason why Backbone provides a persistent client id for the duration of every application session is so that if you need to reference model ids in your generated HTML, you always have something to hang your hat on. If I have '<article data-cid="c530">' ... I can always look up that article, regardless of if the Ajax request to create it on the server has finished or not. With Spine's approach: '<article data-id="D6FD9261-A603-43F7-A1B2-5879E8C7926B">' ... I'm not sure if that id is a real one, or if it's temporary, and can't be used to communicate with the server.
Optimistically (asynchronously, in Alex's terms) doing client-side model logic is tricky enough in the first place, without having to worry about creating an association based off a model's temporary id. I think that having a clear line between a client-only ID and the model's canonical ID is a nice distinction to have.
Favorite links include a Spine on Rails demo video which has some nice convenience advantages over anything I've seen with Backbone (although I think Backbone is the way to go generally) and a set of pros and cons for Backbone which is insightful despite being slightly out of date.
