A Vanity Website
I've been using KnockoutJS quite intensely for several months now and wanted to give some quick thoughts.
First of all Knockout isn't quite as novel as it was when it was introduced several years ago. There are many, many JS front-end libraries and frameworks out there now and they are in very wide use. Let's actually address that right off the bat, Knockout is a library and not a framework. That means you can think of it more as a tool to take care of things like keeping the DOM up-to-date and templating instead of having to build your entire application around the framework. Since it is a library you can use it with or without jQuery. I used it with jQuery and found that they played very nicely together. Bear in the mind that the purpose of many of these libraries and frameworks is to take care of issues like parsing and updating the DOM structure, which means you won't be using as much jQuery as you used to, but I still kept it around for things like map/reduce/foreach on browsers that do not support the ECMAScript 5 standard (eg. IE8). Knockout makes use of the Model-View-ViewModel pattern which may be familiar to you if you've done work with WPF, SilverLight or various other MicroSoft display technologies. It also makes excellent use of the Observer pattern to intelligently track changes to the underlying data that is driving what you see on the page, even carefully managing dependencies which makes just about anything you can build with Knockout perform extremely well.
The syntax of Knockout makes quite a bit of sense as well: all elements it works with are defined by the 'data-bind' attribute. It also has a bunch of standard bindings that keep track of what is happening on the web page; things like clicking, events, focus and checking all have bindings you can easily make use of. And if Knockout doesn't have a binding that you need you can easily roll your own - I actually did this when I wanted jQuery behaviors to trigger at various times and all of this works seamlessly.
Where Knockout falls regarding its competitors is quite interesting. I did research on them before deciding to go with Knockout and as fall as libraries go the most popular option seems to be Backbone.js, which doesn't seem to contain as much functionality as Knockout (especially regarding templating) but seems to be more widely adopted and with a larger selection of add-ons. If I wasn't able to use Knockout I probably would have went with Backbone, though it's usage seems to be declining in the face of more opinionated JS frameworks.
And it's just about impossible to have this conversation without mentioning AngularJS. Google's dynamic web framework is far and away the most popular solution for building Single Page Applications. It doesn't seem to be without its issues however. Controversially, Google has decided to make Angular 2.0 incompatible with its 1.0 version, which leads to an awkward decision: support a lame duck version one or make a jump to 2.0 and lose any compatibility with anything you have done earlier with the framework. Just as bad, Angular's plans included yet another language to learn in AtScript. We already have two 'transpiled' JavaScript languages in CoffeeScript and TypeScript, in addition to Google's own Dart - adding yet another language into the mix seems like overkill. Thankfully Google decided to work with Microsoft and as of last week, TypeScript will be the language on which Angular 2.0 will be built on. As good as this is, I read too many negative reviews of Angular to want to dive into it so far. An absurdly long learning curve and questions regarding performance stand at the top of my list of things to worry about with this platform.
If it seems I'm completely down on the idea of opinionated Dynamic JavaScript platforms however, my counter would be Ember.js. From what I read on it, it seems to be a very well thought-out MVC framework for Single Page Applications. Unlike Angular, the next major version will be fully compatible with the version that came before it. Reading the thoughts of the developers I also came away impressed with the research they have done on this idea of how applications should perform in a client-server, request-response world - an issue that software engineers have been tackling for some time now. Ember.js seems to have a good track record among those that have tried it, but without the support of a mega corporation like Google it seems rather unlikely to take off and come anywhere close to becoming a standard.