If it's double the work, you're doing it wrong. Possibly it's not a good fit for your specific case, or you haven't fully understood the best way to use it.
That is definitely true; there are different cases and I'm still figuring out the best way to use it.
But I think even if your server is just a RESTful API (which I believe is the best way to work with bbone) the code you have for your models (both bbone and server) gets duplicated. The application logic must be on the server as a requirement for the API and if you want the logic to inform the UI, you need to write logic of the model in backbone too. It's similar to how you have to do form validation on the client/server.
Take for example the simple model that some sort of a collection can only have 5 items. This rule has to be set somewhere in a model on the server. It also (should?) be set in a bbone model. If it's not, you could rely on the API's response code when you try to POST the 6th element, but isn't one of the benefits of a client side app supposed to be that you DON'T have to rely on the server for this kind of logic?
This is actually something I think can be solved. There have been some experiments in Ember with building Ember model definitions from the server model definitions. However, in practice I haven't found this to be much of an issue in my development.
