9 ms·

Backbone vs Knockout

89 points by philbo 15y ago

bullsbarry 15y ago
My company is looking to move one of our core apps from Silverlight/RIA Services to ASPnet MVC/Javascript client and we're looking to use Knockout, since it maps well mentally to what we've been doing with XAML in Silverlight. In light of this article, what is a good application structure to use on the client if we do decide to go with Knockout?
- derickbailey 15y ago
  "It depends" - the only viable answer :D But seriously, it largely does depend on the behavior of your application. If you're going to use Knockout to provide wiz-bang editing and binding on single page (as opposed to a slew of jQuery code everywhere), then you might not need much more than Knockout. If you're going to be creating multi-page JavaScript applications within a single page of your site, you should look at combining something like Backbone.js with Knockout, using the Knockback library I linked to in that article. Alternatively, if your looking for good structure for JavaScript applications in general, I have another post that introduces a few of the concepts and links to some great resources, here: http://derickbailey.lostechies.com http://derickbailey.lostechies.com (unfortunately, I can't get the exact URL at the moment... site seems to be slow / not responding. just look for the "Intro to composite JavaScript apps" post)
- IanDrake 15y ago
  I've used knockoutjs on a few projects now and I think I could help, but the article is down, so I don't understand the context of your question. There are several way to structure your app, but it depends on what your app does and how structured it is. On a basic level I structure every page to have a page object to handle events and setup the view model(s). So, for default.aspx, I might have something like: var Page = new function(){ _this = this; $(function(){ //document ready }); $("#dataTable").delegate(".delete",function(){ _this.viewModel.deleteItem(ko.dataFor(this)); }); this.viewModel = new function(){ var _this = this; //set up view model this.observableVal = ko.observable(""); this.deleteItem = function(){ //delete item from VM }; }; }; But then you might want to have a page with multiple view models (ie UserControls that are self contained). This gets a bit tricky, especially if you want the multiple view models to interact. Shoot me an email if you need help.
derickbailey 15y ago
It looks like LosTechies.com is down - maybe all the traffic from HN :) It's being worked on as fast as we can! Sorry about that!
- EricDeb 15y ago
  Get on it I want to read the article! :)
  - lsdafjklsd 15y ago
    Same! I am currently flipping through the tutorials over at Knockout's website, there is a lot going on behind the scenes it seems.
ludicast 15y ago
Can't load article but I'd give angularjs a look as well. It has great databinding features that imitate Adobe Flex in a clean way leading to terse code.
amalag 15y ago
I am a knockoutjs lurker right now. Reading up on it and trying to understand how to use it because I have a project coming up. From what I see it seems great. There is even a Rails-knockout plugin to help bind the knockout objects to Rails models. I am excited about it. I think the binding of data to HTML elements is a perfect fit and natural extension of HTML. I briefly looked at backbone, but it seems very limited in the user experience portion of the puzzle.
- derickbailey 15y ago
  yes, that's an accurate statement. backbone and knockout focus on two different problem spaces: app architecture (backbone) and UI wizardry (knockout). there are several plugins for backbone that bring model binding and other user experience enhancements to it, though. plus, backbone integrates directly with jQuery, so you have access to all of jQuery's libraries and plugins, still.
  - amalag 15y ago
    There is so much proliferation of javascript mvc plugins. From a user point of view, makes deciding very difficult. I basically looked at the two big contenders and went with knockout because it solved what i thought was the more pressing issue. As for model persistence, for my use case, i don't mind if it is only updated to the server with a submit, then i will push some json to the server and i can parse the complex object to save it. It is the javascript stuff that wastes the majority of my time on complex 1 page apps and is why I wanted something to help clear that up. I am sick of writing jquery onchange and other event codes for select boxes, etc. It always seems like an after thought, but if we are designing our ajax functionality from the start then we need a library which can handle it. For instance there is no standard or canonical way to do multiple depdendent cascading dropdowns in rails. For that I will roll it out by requesting a complex object once, then binding the select boxes, and it's done. No onchange events and multiple ajax requests. Anyway there are so many javascript mvc frameworks and i am really not qualified to judge their programming merits. I just have to go with what is likely to be maintained in the future, what works, and what has good documentation and user groups.
- 15y ago
jph 15y ago
Our team is building real projects in both. We especially like Knockout's view bindings. I highly recommend Knockout Model to provide the model, and it also has a good REST API. The Knockout authors are great about updates - new releases this week, and the Knockout Model author just merged our feature request. If you're interested in these, our team's searching for a JavaScript senior developer to work on both these - see http://handl.it http://handl.it
j_s 15y ago
The article points out that the purpose of the two libraries is different (I believe it was saying Knockout focusing on binding and Backbone providing more of the MV* functionality). It also highlights two projects combining them: https://github.com/kmalakoff/knockback https://github.com/kmalakoff/knockback https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding
atomical 15y ago
The documentation on these frameworks isn't great. In fact, it's downright horrible. There are no conventions or standard practices and every tutorial I can find builds an application with these frameworks in a different way.
- kennystone 15y ago
  The docs are ok, but example code and tutorials are lacking. Peepcode showed me the way, but it's not free.
- derickbailey 15y ago
  that's one of the benefits and drawbacks of them, really. it's great to have flexibility, but it makes learning them more difficult because there's no hand-holding. it may require someone that has already formed opinions, to guide you through the learning process.
  - atomical 15y ago
    Well, the hand holding is basically showing you how to build a simple application that has a few buttons and a few input fields. It's sort of like reading the simple 5 line example of how fork() works in a 101 class. The author writes 50 line programs for computer science books. However, when you're writing an application with a bigger scope the simple 50 line example isn't much use.
- jonmc12 15y ago
  I found http://learn.knockoutjs.com/ http://learn.knockoutjs.com/ to be a very nice intro to knockout.js. For Backbone, docs + annotated source are more than sufficient. Best practices - I stick to simple rule of using Views (in backbone) and view models (in knockout) to interact with dom, then using models in both frameworks to sync w/ DB. This keeps code fairly clean, and use of other components of framework relatively straightforward.
maheshs 15y ago
Google cached version http://webcache.googleusercontent.com/search?q=cache:http://lostechies.com/derickbailey/2011/11/22/backbone-vs-knockout/ http://webcache.googleusercontent.com/search?q=cache:http://...
- kablamo 15y ago
  Is there a cache of the cache? Is it just me or is this not loading for other people as well? Update: Click the 'text only' link to avoid page loading forever.
  - latch 15y ago
    Update: Click the 'text only' link to avoid page loading forever. This should be google cache's default mode.
equark 15y ago
Basing my judgement off of implementing a todo list in each, I found Sproutcore's handlebars.js templates with data-binding even nicer than Knockout. Unfortunately it's not clear yet what's happening with Sproutcore 2.0 or whether you could just extract the view layer.
LargeWu 15y ago
We used knockout on a recent project and it has been a disaster. Maybe for trivial UI's it's fine, but for anything complex you spend a lot of trouble hacking around knockout's way of doing things, resulting in a completely unmaintainable mess. I think the plan is to rip out knockout and switch to backbone at our earliest convenience.
- prasunsen 15y ago
  Same here. Many things didn't work at all, other were very painful to do. The project end up nowhere.
- deleted 15y ago
  [deleted]
  - exogen 15y ago
    Hmm, if you're binding every view in your app to a single view model, you're doing it wrong. You're "supposed" to have a model for each view/type/whatever and bind only the necessary markup — not bind the whole page to one big view.
    - deleted 15y ago
      [deleted]
    - Que 15y ago
      I deleted my original comment and the response to your reply; upon review I found them not to lend anything helpful to the conversation but rather to promote argumentative behavior.
- ErrantX 15y ago
  Yep; feeling this pain. I was casting around for a simple way to implement a responsive UI in our latest application and Knockout appeared to be a good option (I'd not come across Backbone at that point). Now it just feels like more work... I have written so many custom bindings it is unreal! (I realise this is, as the author notes, mostly my failing in writing JS :))
gotrythis 15y ago
Here is a new MVC framework looking to displace backbone and knockout: http://derbyjs.com/ http://derbyjs.com/ "Many developers now include a client MVC framework like Backbone to better structure client code. A few have started to use declarative model-view binding libraries, such as Knockout and Angular, to reduce boilerplate DOM manipulation and event bindings. These are great concepts, and adding some structure certainly improves client code. However, they still lead to duplicating rendering code and manually synchronizing changes in increasingly complex server and client code bases. Not only that, each of these components must be manually wired together and packaged for the client."
- nateps 15y ago
  Hey, I am one of the authors of Derby. Knockout and Backbone are pretty different, and they both have good aspects. Knockout's strength is its powerful view-model bindings, and Backbone is targeted at providing an MVC structure. However, neither of these libraries claim to be a complete solution. If you want a more full-featured client framework similar to these, SproutCore is one of the better ones right now. The reason we started working on Derby, is that none of these frameworks offer a full-stack solution. Backbone and SproutCore will provide better structure and some automation of client-server data syncing. However, they still require manually creating appropriate server routes that handle AJAX requests and communicate with a database. They may provide client-side routing, but these routes are totally different from the server routes, so if you want to use the same URLs, you have to duplicate routing code. SproutCore uses Handlebars, so you might be able to render the same templates on the server for faster page rendering, and non-JavaScript browser or search engine crawler accessibility. However, this will require writing a bunch of custom server code to pull out the right data and render the templates. In addition, none of these frameworks provide tools to deal with data conflicts. Conflicts are inevitable in a multiple users realtime application, especially when supporting offline. Derby's focus is to unify as much code between server and client and to provide automatic realtime syncing among all models and views. This approach requires less code, delivers faster load times, provides instant client-side rendering from full pages to individual data bindings, and supports offline by default. It's a work in progress, but let us know what you think about it so far.
jonmc12 15y ago
I've used both frameworks on a recent project. I was drawn to backbone because of flexibility and I can see code all the way down. As I have worked with Knockout, I've come to enjoy the automatic DOM syncing - it really simplifies managing bindings and content display. My major issue with Knockout.js is testability. It does not come out of the box with a very elegant way to trace your chained dependencies, or put meaningful automated tests in place using Jasmine or equivalent. I think this is mostly a function of the mindset of the community. This is problematic when your app gets complex - you waste countless hours chasing around silent failures or meaningless stack traces. The Knockout.js community itself is a little funny - some people really know their stuff, but majority seem to want to take code off the shelf and hack up quick prototypes (which I think is a good use of knockout). However, the thing that is really impressive is that the community can communicate back and forth using JS fiddle. No long pasted stack traced or error codes need to be discussed - just paste a link to the JS fiddle of your app code and others can respond with their own JS fiddle. It really is an evolved form of communication for discussing code. Lastly, I had not seen this before - https://github.com/kmalakoff/knockback https://github.com/kmalakoff/knockback - I think this is a great idea. First thing I picked up knockout.js I integrated the backbone model / collection. It just seems like the proper use of the 2 libraries. Knockout.js syncs with DOM off the shelf, Backbone syncs with the DB quite nicely. Glue them together with a clean app architecture and you have an elegant way to sync your DOM with the DB. I think this is the next generation of these apps - full sync from DOM to DB perhaps with a persistent store and data validation in the client.
rimantas 15y ago
Reasons why I prefer backbone: - It's lightweight. I am a bit obsessed with client-side optimization, so that's a plus in my eyes. - I am not a big fan of binding via html attributes. Yes, there is a way to do that script-only way in Knockout too, but it was neither fun nor appeared very clean. - Backbone allows to use either jQuery or Zepto as DOM manipulation library. - Backbone is template engine agnostic. The situation with templating in KO seemed a bit muddy to me. - Backbone has routing built-in. With KO I'd have to use something like Crossroads.js thus adding even more weight. In short you may need to write a bit more code in backbone to get the same that you can have with almost no code in KO, but on the other hand Backbone feels much more flexible and less restricting. YMMV.
outside1234 15y ago
has anyone used sproutcore? wondering how that would fare in against these contenders?
jashkenas 15y ago
As someone who works on Backbone.js, the level of conversation in the blog post and this thread is a bit disheartening. Client-side libraries aren't just matrices of features to be checked off ... we're talking about the style in which you think about and work with the concepts that construct your user interface. I'd tend to think that attempts to glom together Backbone.js and Knockout.js will produce something less than the sum of their parts. Here's Knockout's documentation: http://knockoutjs.com/documentation/introduction.html http://knockoutjs.com/documentation/introduction.html Most of Knockout's API deals with binding JavaScript objects to web forms. If all of your web app's UI is essentially a series of web forms, then great! You're all set. The Knockout examples demonstrate this ability: http://knockoutjs.com/examples/ http://knockoutjs.com/examples/ However, if your UI starts to move in interesting directions beyond filling out a series of forms, then Knockout doesn't have much to offer you (see LargeWu's comments on this page). On the other hand, Backbone's philosophy is that your UI is your business -- jQuery is already great at extracting data from forms and other elements in the DOM, and there are already a large number of wonderful templating libraries for rendering HTML from JS objects. Instead, it focuses on helping you model your data in the browser: providing events you can observe whenever a model changes state, adding essential functions like "map", "filter", "find", "groupBy" and "any" to collections of models, giving you simpler declarative bindings for DOM events in your views, so that you don't have to worry about whether a particular piece of HTML is visible on screen or not, and so on... But really, the best proof of "UI wizardry" is in the pudding. If you haven't scrolled through it recently, I encourage you to check out some of the amazing apps built with Backbone over the past year: http://backbonejs.org/#examples http://backbonejs.org/#examples (with all due apologies for boosterism)
- derickbailey 15y ago
  disheartened? we've basically said the same thing. as for the wizardry - it's jquery (or zepto or something else), not backbone that does this. while backbone integrates with and uses jquery heavily in the views, i don't think it's a fair claim to say backbone creates facilitates those user experiences. it helps us organize our code effectively so that we can create those user experiences in a well structured manner. and come on, Jeremy... you know how much I love backbone! it's 80% of what I blog about these days! :)
dcoupl 15y ago
Its important to recognize that Backbone is a framework and Knockout is a library. These are very different things! Because of this, comparing Backbone and Knockout side-by-side is inappropriate; kinda like comparing a building with a vehicle. For the record, Knockout handles way more than just forms. The statement that Knockout doesn't offer much beyond forms is simply false. After writing code using both, on my next app I will use all of them: - Backbone for application structure and the client-side model layer functionality. Backbone is good at this. - Knockout to make handling user-triggered events a breeze, keep data in sync across views and layouts automatically, and to keep my markup and JS code tidy and separate with client-side templating. Knockout is good at this. - jQuery to interface with "low-level" constructs such as DOM elements. jQuery is good at this. In this set up, Backbone is the framework, Knockout is just another library being used, and jQuery is just another library being used. :-)
kogir 15y ago
I never understood the "knockout vs backbone" mentality. Knockout binds your UI model to display elements, and backbone binds your server model to your display model. It can absolutely make sense to have two models for two very different interactions with the same data - UI and REST server calls. Anyone who's written a substantial Silverlight or WPF app already has done this. Or am I totally crazy? I intend to use both in my latest project, and I'll see how it goes.
- wahnfrieden 15y ago
  Just a nitpick, Backbone uses RPC, not REST. URLs are essentially hardcoded in the client - Backbone constructs URLs like e.g. "/collection[/id]" which is totally RPC. Which is not a bad thing, it's just not REST.
  - catch23 15y ago
    maybe it's not REST's ivory tower definition, but it is most definitely REST style urls the way that everyone else interprets REST. Also, you construct your own urls in backbone, so it's technically adaptable to whatever, but in Backbone.sync, it does the usual REST verbs to http actions.
    - wahnfrieden 15y ago
      Yep, that's just good HTTP usage. REST doesn't care what your URLs look like, as long as it is not the client which constructs them. It helps to use terms more precisely. I don't care if Backbone isn't REST.
kreek 15y ago
I've tried both Backbone (and Spine) and both were great for small to medium sized apps. I hadn't heard of Knockout before, but from my experience data binding (two or one way) works, again, great for small apps but falls apart when you need to customize it. My experience in Backbone was that things are a bit too tightly coupled. 'Controllers' (which are called views) are mapped to templates (the actual views). Views have a Model reference directly in the view. Again, for small apps this works great and enables data-binding by tying model changes to view updates (render). For large apps, in regards to maintainability, I think you really need the C in MVC to stand for Command. Any type of undo/redo needs the command pattern. Commands are great as well as you can throw them away or add them without affecting the rest of your application. I also wanted a system wide messaging system, or events that can be dispatched and received by any actor in the framework (rather than bound directly between actors). In the end I rolled my own MVC framework based on traits.js (and borrows from Backbone, Spine, and some Flex frameworks), it's far from complete (no remote persistance yet) but it solved some of the issues I had with current JS MVC frameworks. https://github.com/kreek/MCjs/blob/master/js/mc.js https://github.com/kreek/MCjs/blob/master/js/mc.js
- derickbailey 15y ago
  an event aggregator in Backbone: var vent = _.extend({}, Backbone.Events); done. see also http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/ http://lostechies.com/derickbailey/2011/07/19/references-rou... for more info on using it, and http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/ http://lostechies.com/derickbailey/2011/11/17/introduction-t... for more info on creating larger apps w/ backbone
  - kreek 15y ago
    Thanks Derick, I'd actually seen that on your site before and used it with Backbone.
sgt 15y ago
As for the hybrid, is it safe to use projects like these from a business and maintenance point of view? That also goes for backbone.js and knockout.js for that matter. What if none of these projects exist 2 years ahead in time, and your web app depends upon them?
- thomaslangston 15y ago
  I have no knowledge of the hybrid or backbone, but knockout is open source and has a significant mind share. If it did go away, it would be for something as good or better that existing apps could port to. If you didn't port you could fix any bugs yourself; I don't see that as more difficult than implementing the library's features yourself.
dylanhassinger 15y ago
I'm a big fan of Knockout. I made a demo kit to supplement the official docs, get it here: http://notes.dylanized.com/knockoutjs-demo-kit-now-on-github http://notes.dylanized.com/knockoutjs-demo-kit-now-on-github That said, the comments here are right. Knockout is good for scenarios where a dynamic UI is needed. For a more data intensive app, Backbone is usually a better choice, but at a cost. Excited to see what happens with Knockback....

89 points by philbo 15y ago

My company is looking to move one of our core apps from Silverlight/RIA Services to ASPnet MVC/Javascript client and we're looking to use Knockout, since it maps well mentally to what we've been doing with XAML in Silverlight. In light of this article, what is a good application structure to use on the client if we do decide to go with Knockout?

derickbailey 15y ago
"It depends" - the only viable answer :D But seriously, it largely does depend on the behavior of your application. If you're going to use Knockout to provide wiz-bang editing and binding on single page (as opposed to a slew of jQuery code everywhere), then you might not need much more than Knockout. If you're going to be creating multi-page JavaScript applications within a single page of your site, you should look at combining something like Backbone.js with Knockout, using the Knockback library I linked to in that article. Alternatively, if your looking for good structure for JavaScript applications in general, I have another post that introduces a few of the concepts and links to some great resources, here: http://derickbailey.lostechies.com http://derickbailey.lostechies.com (unfortunately, I can't get the exact URL at the moment... site seems to be slow / not responding. just look for the "Intro to composite JavaScript apps" post)
IanDrake 15y ago
I've used knockoutjs on a few projects now and I think I could help, but the article is down, so I don't understand the context of your question. There are several way to structure your app, but it depends on what your app does and how structured it is. On a basic level I structure every page to have a page object to handle events and setup the view model(s). So, for default.aspx, I might have something like: var Page = new function(){ _this = this; $(function(){ //document ready }); $("#dataTable").delegate(".delete",function(){ _this.viewModel.deleteItem(ko.dataFor(this)); }); this.viewModel = new function(){ var _this = this; //set up view model this.observableVal = ko.observable(""); this.deleteItem = function(){ //delete item from VM }; }; }; But then you might want to have a page with multiple view models (ie UserControls that are self contained). This gets a bit tricky, especially if you want the multiple view models to interact. Shoot me an email if you need help.

derickbailey 15y ago

It looks like LosTechies.com is down - maybe all the traffic from HN :) It's being worked on as fast as we can! Sorry about that!

EricDeb 15y ago
Get on it I want to read the article! :)
- lsdafjklsd 15y ago
  Same! I am currently flipping through the tutorials over at Knockout's website, there is a lot going on behind the scenes it seems.

ludicast 15y ago

Can't load article but I'd give angularjs a look as well. It has great databinding features that imitate Adobe Flex in a clean way leading to terse code.

amalag 15y ago

I am a knockoutjs lurker right now. Reading up on it and trying to understand how to use it because I have a project coming up. From what I see it seems great. There is even a Rails-knockout plugin to help bind the knockout objects to Rails models. I am excited about it. I think the binding of data to HTML elements is a perfect fit and natural extension of HTML. I briefly looked at backbone, but it seems very limited in the user experience portion of the puzzle.

derickbailey 15y ago
yes, that's an accurate statement. backbone and knockout focus on two different problem spaces: app architecture (backbone) and UI wizardry (knockout). there are several plugins for backbone that bring model binding and other user experience enhancements to it, though. plus, backbone integrates directly with jQuery, so you have access to all of jQuery's libraries and plugins, still.
- amalag 15y ago
  There is so much proliferation of javascript mvc plugins. From a user point of view, makes deciding very difficult. I basically looked at the two big contenders and went with knockout because it solved what i thought was the more pressing issue. As for model persistence, for my use case, i don't mind if it is only updated to the server with a submit, then i will push some json to the server and i can parse the complex object to save it. It is the javascript stuff that wastes the majority of my time on complex 1 page apps and is why I wanted something to help clear that up. I am sick of writing jquery onchange and other event codes for select boxes, etc. It always seems like an after thought, but if we are designing our ajax functionality from the start then we need a library which can handle it. For instance there is no standard or canonical way to do multiple depdendent cascading dropdowns in rails. For that I will roll it out by requesting a complex object once, then binding the select boxes, and it's done. No onchange events and multiple ajax requests. Anyway there are so many javascript mvc frameworks and i am really not qualified to judge their programming merits. I just have to go with what is likely to be maintained in the future, what works, and what has good documentation and user groups.
15y ago

jph 15y ago

Our team is building real projects in both. We especially like Knockout's view bindings. I highly recommend Knockout Model to provide the model, and it also has a good REST API. The Knockout authors are great about updates - new releases this week, and the Knockout Model author just merged our feature request. If you're interested in these, our team's searching for a JavaScript senior developer to work on both these - see http://handl.it http://handl.it

j_s 15y ago

The article points out that the purpose of the two libraries is different (I believe it was saying Knockout focusing on binding and Backbone providing more of the MV* functionality). It also highlights two projects combining them: https://github.com/kmalakoff/knockback https://github.com/kmalakoff/knockback https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding

atomical 15y ago

The documentation on these frameworks isn't great. In fact, it's downright horrible. There are no conventions or standard practices and every tutorial I can find builds an application with these frameworks in a different way.

kennystone 15y ago
The docs are ok, but example code and tutorials are lacking. Peepcode showed me the way, but it's not free.
derickbailey 15y ago
that's one of the benefits and drawbacks of them, really. it's great to have flexibility, but it makes learning them more difficult because there's no hand-holding. it may require someone that has already formed opinions, to guide you through the learning process.
- atomical 15y ago
  Well, the hand holding is basically showing you how to build a simple application that has a few buttons and a few input fields. It's sort of like reading the simple 5 line example of how fork() works in a 101 class. The author writes 50 line programs for computer science books. However, when you're writing an application with a bigger scope the simple 50 line example isn't much use.
jonmc12 15y ago
I found http://learn.knockoutjs.com/ http://learn.knockoutjs.com/ to be a very nice intro to knockout.js. For Backbone, docs + annotated source are more than sufficient. Best practices - I stick to simple rule of using Views (in backbone) and view models (in knockout) to interact with dom, then using models in both frameworks to sync w/ DB. This keeps code fairly clean, and use of other components of framework relatively straightforward.

maheshs 15y ago

Google cached version http://webcache.googleusercontent.com/search?q=cache:http://lostechies.com/derickbailey/2011/11/22/backbone-vs-knockout/ http://webcache.googleusercontent.com/search?q=cache:http://...

kablamo 15y ago
Is there a cache of the cache? Is it just me or is this not loading for other people as well? Update: Click the 'text only' link to avoid page loading forever.
- latch 15y ago
  Update: Click the 'text only' link to avoid page loading forever. This should be google cache's default mode.

equark 15y ago

Basing my judgement off of implementing a todo list in each, I found Sproutcore's handlebars.js templates with data-binding even nicer than Knockout. Unfortunately it's not clear yet what's happening with Sproutcore 2.0 or whether you could just extract the view layer.

LargeWu 15y ago

We used knockout on a recent project and it has been a disaster. Maybe for trivial UI's it's fine, but for anything complex you spend a lot of trouble hacking around knockout's way of doing things, resulting in a completely unmaintainable mess. I think the plan is to rip out knockout and switch to backbone at our earliest convenience.

prasunsen 15y ago
Same here. Many things didn't work at all, other were very painful to do. The project end up nowhere.
deleted 15y ago
[deleted]
- exogen 15y ago
  Hmm, if you're binding every view in your app to a single view model, you're doing it wrong. You're "supposed" to have a model for each view/type/whatever and bind only the necessary markup — not bind the whole page to one big view.
  - deleted 15y ago
    [deleted]
  - Que 15y ago
    I deleted my original comment and the response to your reply; upon review I found them not to lend anything helpful to the conversation but rather to promote argumentative behavior.
ErrantX 15y ago
Yep; feeling this pain. I was casting around for a simple way to implement a responsive UI in our latest application and Knockout appeared to be a good option (I'd not come across Backbone at that point). Now it just feels like more work... I have written so many custom bindings it is unreal! (I realise this is, as the author notes, mostly my failing in writing JS :))

gotrythis 15y ago

Here is a new MVC framework looking to displace backbone and knockout: http://derbyjs.com/ http://derbyjs.com/ "Many developers now include a client MVC framework like Backbone to better structure client code. A few have started to use declarative model-view binding libraries, such as Knockout and Angular, to reduce boilerplate DOM manipulation and event bindings. These are great concepts, and adding some structure certainly improves client code. However, they still lead to duplicating rendering code and manually synchronizing changes in increasingly complex server and client code bases. Not only that, each of these components must be manually wired together and packaged for the client."

nateps 15y ago
Hey, I am one of the authors of Derby. Knockout and Backbone are pretty different, and they both have good aspects. Knockout's strength is its powerful view-model bindings, and Backbone is targeted at providing an MVC structure. However, neither of these libraries claim to be a complete solution. If you want a more full-featured client framework similar to these, SproutCore is one of the better ones right now. The reason we started working on Derby, is that none of these frameworks offer a full-stack solution. Backbone and SproutCore will provide better structure and some automation of client-server data syncing. However, they still require manually creating appropriate server routes that handle AJAX requests and communicate with a database. They may provide client-side routing, but these routes are totally different from the server routes, so if you want to use the same URLs, you have to duplicate routing code. SproutCore uses Handlebars, so you might be able to render the same templates on the server for faster page rendering, and non-JavaScript browser or search engine crawler accessibility. However, this will require writing a bunch of custom server code to pull out the right data and render the templates. In addition, none of these frameworks provide tools to deal with data conflicts. Conflicts are inevitable in a multiple users realtime application, especially when supporting offline. Derby's focus is to unify as much code between server and client and to provide automatic realtime syncing among all models and views. This approach requires less code, delivers faster load times, provides instant client-side rendering from full pages to individual data bindings, and supports offline by default. It's a work in progress, but let us know what you think about it so far.

jonmc12 15y ago

I've used both frameworks on a recent project. I was drawn to backbone because of flexibility and I can see code all the way down. As I have worked with Knockout, I've come to enjoy the automatic DOM syncing - it really simplifies managing bindings and content display. My major issue with Knockout.js is testability. It does not come out of the box with a very elegant way to trace your chained dependencies, or put meaningful automated tests in place using Jasmine or equivalent. I think this is mostly a function of the mindset of the community. This is problematic when your app gets complex - you waste countless hours chasing around silent failures or meaningless stack traces. The Knockout.js community itself is a little funny - some people really know their stuff, but majority seem to want to take code off the shelf and hack up quick prototypes (which I think is a good use of knockout). However, the thing that is really impressive is that the community can communicate back and forth using JS fiddle. No long pasted stack traced or error codes need to be discussed - just paste a link to the JS fiddle of your app code and others can respond with their own JS fiddle. It really is an evolved form of communication for discussing code. Lastly, I had not seen this before - https://github.com/kmalakoff/knockback https://github.com/kmalakoff/knockback - I think this is a great idea. First thing I picked up knockout.js I integrated the backbone model / collection. It just seems like the proper use of the 2 libraries. Knockout.js syncs with DOM off the shelf, Backbone syncs with the DB quite nicely. Glue them together with a clean app architecture and you have an elegant way to sync your DOM with the DB. I think this is the next generation of these apps - full sync from DOM to DB perhaps with a persistent store and data validation in the client.

rimantas 15y ago

Reasons why I prefer backbone: - It's lightweight. I am a bit obsessed with client-side optimization, so that's a plus in my eyes. - I am not a big fan of binding via html attributes. Yes, there is a way to do that script-only way in Knockout too, but it was neither fun nor appeared very clean. - Backbone allows to use either jQuery or Zepto as DOM manipulation library. - Backbone is template engine agnostic. The situation with templating in KO seemed a bit muddy to me. - Backbone has routing built-in. With KO I'd have to use something like Crossroads.js thus adding even more weight. In short you may need to write a bit more code in backbone to get the same that you can have with almost no code in KO, but on the other hand Backbone feels much more flexible and less restricting. YMMV.

outside1234 15y ago

has anyone used sproutcore? wondering how that would fare in against these contenders?

jashkenas 15y ago

As someone who works on Backbone.js, the level of conversation in the blog post and this thread is a bit disheartening. Client-side libraries aren't just matrices of features to be checked off ... we're talking about the style in which you think about and work with the concepts that construct your user interface. I'd tend to think that attempts to glom together Backbone.js and Knockout.js will produce something less than the sum of their parts. Here's Knockout's documentation: http://knockoutjs.com/documentation/introduction.html http://knockoutjs.com/documentation/introduction.html Most of Knockout's API deals with binding JavaScript objects to web forms. If all of your web app's UI is essentially a series of web forms, then great! You're all set. The Knockout examples demonstrate this ability: http://knockoutjs.com/examples/ http://knockoutjs.com/examples/ However, if your UI starts to move in interesting directions beyond filling out a series of forms, then Knockout doesn't have much to offer you (see LargeWu's comments on this page). On the other hand, Backbone's philosophy is that your UI is your business -- jQuery is already great at extracting data from forms and other elements in the DOM, and there are already a large number of wonderful templating libraries for rendering HTML from JS objects. Instead, it focuses on helping you model your data in the browser: providing events you can observe whenever a model changes state, adding essential functions like "map", "filter", "find", "groupBy" and "any" to collections of models, giving you simpler declarative bindings for DOM events in your views, so that you don't have to worry about whether a particular piece of HTML is visible on screen or not, and so on... But really, the best proof of "UI wizardry" is in the pudding. If you haven't scrolled through it recently, I encourage you to check out some of the amazing apps built with Backbone over the past year: http://backbonejs.org/#examples http://backbonejs.org/#examples (with all due apologies for boosterism)

derickbailey 15y ago
disheartened? we've basically said the same thing. as for the wizardry - it's jquery (or zepto or something else), not backbone that does this. while backbone integrates with and uses jquery heavily in the views, i don't think it's a fair claim to say backbone creates facilitates those user experiences. it helps us organize our code effectively so that we can create those user experiences in a well structured manner. and come on, Jeremy... you know how much I love backbone! it's 80% of what I blog about these days! :)

dcoupl 15y ago

Its important to recognize that Backbone is a framework and Knockout is a library. These are very different things! Because of this, comparing Backbone and Knockout side-by-side is inappropriate; kinda like comparing a building with a vehicle. For the record, Knockout handles way more than just forms. The statement that Knockout doesn't offer much beyond forms is simply false. After writing code using both, on my next app I will use all of them: - Backbone for application structure and the client-side model layer functionality. Backbone is good at this. - Knockout to make handling user-triggered events a breeze, keep data in sync across views and layouts automatically, and to keep my markup and JS code tidy and separate with client-side templating. Knockout is good at this. - jQuery to interface with "low-level" constructs such as DOM elements. jQuery is good at this. In this set up, Backbone is the framework, Knockout is just another library being used, and jQuery is just another library being used. :-)

kogir 15y ago

I never understood the "knockout vs backbone" mentality. Knockout binds your UI model to display elements, and backbone binds your server model to your display model. It can absolutely make sense to have two models for two very different interactions with the same data - UI and REST server calls. Anyone who's written a substantial Silverlight or WPF app already has done this. Or am I totally crazy? I intend to use both in my latest project, and I'll see how it goes.

wahnfrieden 15y ago
Just a nitpick, Backbone uses RPC, not REST. URLs are essentially hardcoded in the client - Backbone constructs URLs like e.g. "/collection[/id]" which is totally RPC. Which is not a bad thing, it's just not REST.
- catch23 15y ago
  maybe it's not REST's ivory tower definition, but it is most definitely REST style urls the way that everyone else interprets REST. Also, you construct your own urls in backbone, so it's technically adaptable to whatever, but in Backbone.sync, it does the usual REST verbs to http actions.
  - wahnfrieden 15y ago
    Yep, that's just good HTTP usage. REST doesn't care what your URLs look like, as long as it is not the client which constructs them. It helps to use terms more precisely. I don't care if Backbone isn't REST.

kreek 15y ago

I've tried both Backbone (and Spine) and both were great for small to medium sized apps. I hadn't heard of Knockout before, but from my experience data binding (two or one way) works, again, great for small apps but falls apart when you need to customize it. My experience in Backbone was that things are a bit too tightly coupled. 'Controllers' (which are called views) are mapped to templates (the actual views). Views have a Model reference directly in the view. Again, for small apps this works great and enables data-binding by tying model changes to view updates (render). For large apps, in regards to maintainability, I think you really need the C in MVC to stand for Command. Any type of undo/redo needs the command pattern. Commands are great as well as you can throw them away or add them without affecting the rest of your application. I also wanted a system wide messaging system, or events that can be dispatched and received by any actor in the framework (rather than bound directly between actors). In the end I rolled my own MVC framework based on traits.js (and borrows from Backbone, Spine, and some Flex frameworks), it's far from complete (no remote persistance yet) but it solved some of the issues I had with current JS MVC frameworks. https://github.com/kreek/MCjs/blob/master/js/mc.js https://github.com/kreek/MCjs/blob/master/js/mc.js

derickbailey 15y ago
an event aggregator in Backbone: var vent = _.extend({}, Backbone.Events); done. see also http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/ http://lostechies.com/derickbailey/2011/07/19/references-rou... for more info on using it, and http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/ http://lostechies.com/derickbailey/2011/11/17/introduction-t... for more info on creating larger apps w/ backbone
- kreek 15y ago
  Thanks Derick, I'd actually seen that on your site before and used it with Backbone.

sgt 15y ago

As for the hybrid, is it safe to use projects like these from a business and maintenance point of view? That also goes for backbone.js and knockout.js for that matter. What if none of these projects exist 2 years ahead in time, and your web app depends upon them?

thomaslangston 15y ago
I have no knowledge of the hybrid or backbone, but knockout is open source and has a significant mind share. If it did go away, it would be for something as good or better that existing apps could port to. If you didn't port you could fix any bugs yourself; I don't see that as more difficult than implementing the library's features yourself.

dylanhassinger 15y ago

I'm a big fan of Knockout. I made a demo kit to supplement the official docs, get it here: http://notes.dylanized.com/knockoutjs-demo-kit-now-on-github http://notes.dylanized.com/knockoutjs-demo-kit-now-on-github That said, the comments here are right. Knockout is good for scenarios where a dynamic UI is needed. For a more data intensive app, Backbone is usually a better choice, but at a cost. Excited to see what happens with Knockback....