4 ms·

I have a hard time seeing the advantages of backbone.js over something simpler like knockout.js. Is it that good? Is it a question of having a complicated enoug

• conesus 15y ago
  Just look at the examples of what was built using Backbone.js vs. Knockout.js. http://backbonejs.org/#examples http://backbonejs.org/#examples vs. http://knockoutjs.com/examples/ http://knockoutjs.com/examples/. Backbone.js has many more real-world examples that demonstrate it's flexibility and ease.
  • Lazare 15y ago
    Those aren't really comparable links. The Backbone link goes to a "who is using Backbone" page. Which is nice, and quite convincing that Backbone is a serious library used in some huge projects. The Knockout link, however, goes to a "how do you use Knockout" page. Which is also nice, and a very useful documentation source that Backbone is sadly lacking. But as a new developer, if anything, the Knockout link is a better reason to pick it. Good documentation goes a LOT further than knowing that Groupon has selected the library, in my book.
• Lazare 15y ago
  First, both Backbone and Knockout are very simple, and if anything Backbone is simpler than Knockout. Neither is rally comparable to a full framework like Rails or Django, and neither has much "magic" either. Both could be replaced with a very small collection of standalone JS libraries. Backbone is, basically, just some "smart" models and collections that know how to consume and persist to a REST data source, and a router. If you want anything else - like templates, or any support for relational data, or two way binding of your data to your rendered HTML, then you need to turn to standalone libraries or plugins, or just write it yourself. (Note: There's some kickass template libraries around, but in my experience the only data binding options are Backbone.ModelBinding and Synapse, and neither of them is production ready. I also had a bad experience with Backbone relational. YMMV) Also, Backbone is, by design, very much NOT opinionated. You can structure your code however you want. That's good if you know what you're doing, but a pain in the ass if you're coming at it fresh from Django or something. Knockout is, basically, just a fantastic data binding library with integrated support for a decent template library. If you need smart models, or to persist stuff to a REST data store, or routing, then you need to use standalone libraries or roll your own. (Note: Writing your own code to load and save models is actually easy. And as far as routing goes, there's a million solution. I like Sammy though.) Also, it's a little more opinionated, and I like the docs better - they give concrete examples of how to do things, rather than vague "some people like to implement this via X, but others prefer to Y" hints, like Backbone. In short, neither is going to give you the full set of tools you want; you should pick the one that is more closely tailored to what you are planning, but always keeping in mind that you're going to need to fill in a lot of gaps yourself. (Hell, some people use both libraries at once; there's actually not a lot of overlap.) So it's not really a question of how complicated the webapp is, but more a question of what kind of webapp it is, and what features it needs. If I was going to write a streaming music player (or something else that basically needs to be a simple GUI over some very complex JS code), I'd be inclined to turn to Backbone. I believe Pandora used Backbone for their recent interface rewrite, and PeepCode has an excellent series of tutorials showing someone building a music player in Backbone you can follow along with. On the other hand, if I was building any form of CRUD app, especially one with a very complex or rich interface, and especially one that needs to edit deeply nested relational data, I'd be strongly pulled towards Knockout. You could do it in Backbone, but you'd do it by, basically, rewriting the core of Knockout in your own code, while getting only minimal benefit from Backbone. TL;DR summary: Neither is really simpler. Neither is more appropriate for more complex apps. They solve different problems. (But personally, I had some pretty complex problems to solve, and after struggling with Backbone for weeks because all the cool kids were using it, I eventually rewrote my app in Knockout, and breathed a sigh of relief. More functionality in less time with fewer bugs and prettier code. But that's me, for my app. Different programmer or a different app? Different story. And keep in mind there's like, 15 different JS frameworks out there, some of which also look awesome. Serenade and Ember in particular...)
  • herge 15y ago
    Cool, so a CRUD app is easier in knockout, while anything that doesn't directly display the data is easier in backbone.