4 ms·
In summary, one should use spine because it: is 2.6k smaller is 7k and still split into multiple files doesn't have collections by default does
by ynniv 15y ago
In summary, one should use spine because it:
is 2.6k smaller
is 7k and still split into multiple files
doesn't have collections
by default doesn't verify that changes were preserved
must use 'id' for object identifiers
includes a tiny subset of underscore
is written in a functionally equivalent but syntactically
different variant of JS that requires additional tooling
... I'm unconvinced. Do yourself a favor and use backbone.
- Volpe 15y agoCherry pick much...?
- deleted 15y ago[deleted]
- burnvictim 15y agoI found the article to be a little more balanced than that. But, basically once I saw that spine.js is written in coffeescript I wasn't really interested.
- chc 15y agoThat's about as rational as being uninterested because the author is a Gemini. CoffeeScript compiles to JavaScript. They are 100% interoperable.
- huskyr 15y agoIt's not just the source. A lot of the documentation is only available with CS examples (even though they provide a switcher at the top of the page), which also means the ecosystem (in terms of people writing blogposts about Spine) is divided in Javascript and Coffeescript examples.
- laserDinosaur 15y agoThis is the exact problem I ran into.
- dgudkov 15y agoIs 2.6k really a difference nowadays?
- DrJ 15y agoStrangely enough Spine models generate a client identifier that is set on the id before saving to the server and is overwritten as the model is synced for the first time. This is in my opinion very confusing and only increases the likelihood of introducing bugs. I'm surprised he did redress this at the summary