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 Knock

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.