Title: KnockoutJS vs CanJS
This article will be a comparison of KnockoutJS to CanJS. Many developers have asked us how CanJS compares directly to other libraries. While often not a apples to apples comparison, having a good understanding of the differences between MV* libraries will help you make the right choice for how to build your apps.
Knockout's MVVM Pattern - Live bound templates coupled with observable objects, heavily influenced the development of CanJS.
But Knockout basically stops there, a library aiming at providing live bound templates and observable objects. CanJS is that and so much more (model layer, routing, better widget modularity support).
If you choose Knockout to build your large JavaScript application
<button data-bind="click: incrementClickCounter">Click me</button>
Here's a few disadvantages to this:
Performance: You can't do event delegation with this style of event binding, so the performance of large lists will be much worse.
Determinism: You can name these handlers anything, so you lose any sort of determinism when looking at your control code. In Can, you must name your event handlers "button click" or they won't work.
Readability: Your view code becomes littered with inline event bindings, making it harder to read and maintain, and heavily dependent on the control using it. There's no real way to create reusable views. You can do almost the same thing in normal HTML by using DOM level 0 event handlers: onclick="myfunc()". But no one does that anymore because its not a best practice to mix javascript in your HTML.
Memory Leaks: There's a common pattern of needing a control to bind to an event outside its parent (to close a menu when you click outside of it). This will always cause a memory leak, which often becomes a big problem in large apps. In Can we fix this problem and prevent the leak. Knockout provides no support for this.
Knockout also lacks a lot of key things that are very easy In Can and part of its core, most notably:
Model Layer: There is none in Knockout. You are left to your own devices.
No opt-out live binding: Often you want live binding to not happen. In Knockout there's no easy way to "turn it off".
Routes: Can has can.route that makes it super easy to create back-button support for JS apps. Backbone doesn't support this.
Build process: There's no built in way to include the knockout templates in a build process, so they'll load separately in production and slow down page load times.
observe power: delegate, setters, validations, attribute conversion/serialization hooks, backup/restore, batching events
fixtures
if you want a very lightweight observe layer, knockout is that….but if you're building a real application, canjs is definitely the better option…with support and consulting
modularity/testability...no built in way to load external templates, tied to HTML, so you can't really wrap each module in a test...CanJS has very clean modules (controls and models)...controls are the centerpiece of the app, defining dependencies (including model and view)....