I wouldn't call it a "fixed" version of Backbone. It changes some things I'm not overly concerned about (getters) and replaces collections with something that at first glance appears less useful.

I like collections, they give me a good place to put any logic and state involved with groups of models. If need be I can have multiple collections dealing with the same model class, each with whatever varied behavior needs supporting. In spine it looks like I get to manage all of that myself, which appears to be a trade of versatility for simplicity.

Not trying to knock Spine, I just don't like it when "oh it's a fixed X" is used to mean "it's a version of X that does things the way I like". There are a lot of actually broken projects out there, Backbone is not one of them.

Yes, I would say that if want to emulate what you're doing with Collections in Spine, it's just a case of subclassing the model. This makes more sense imho, and may lead to even further code re-use.

@awj has this right. I very much appreciate projects like Spine and wish it great success, but it's an alternative, not a fixed version of the same thing.

Pseudo-setters exist in Backbone for a very good reason: change events, and Collections are (IMO) more than 50% of the entire usefulness of Backbone in the first place. The point is that you have solid aggregation and analysis functions to base your model manipulations on: map, reduce, filter, find, every, some, etc etc.