Having worked with Knockout on a fairly large project, I personally liked it as a normally server-side developer - however, it got mixed reviews from our purely frontend developers.<p>For me, there are several things I like about Knockout as someone who's not a primarily frontend developer:<p>1) Obviousness of purpose. The thing I hate the most about frontend development is the lack of visibility into what is actually bound to an object. When I run into UI code that's not using some kind of framework like Knockout, inevitably the UI interactions are typically performed with jQuery bindings, and often they aren't terribly straightforward to find for anyone who didn't initially develop it ("what, you bound a mouseover action to everything that fits '.mouseoverable > li > ul > li > .mousey'?")<p>2) Clearly defined interaction models. I like creating and populating the ViewModel, and thus having a very clear place in the Javascript where I know the business logic and data for the frontend are going to live. When I create the ViewModel as its own Javascript object, I can define the full contract of what data the application needs and what operations can be done against it in a manner that I can quickly locate and fix up later.<p>3) Syncing of frontend state with data state. (of course, this is an obvious benefit, but...) I love that, once I've defined these obvious bindings, I can then focus more on my model and less on what is bound to that model. It gives me the ability to separate out my concerns, at least more than a scattering of one-off jQuery bindings would.<p>Knockout provides an obviousness of binding not only because all interactions between the UI, the user, and the model are supposed to happen through these bindings, but because the bindings are supposed to live on the element being interacted with/displayed itself. This made a huge difference for me, as someone who likes to see an obvious relationship between the view and the underlying logic that's modifying or creating that view. The concept of observable properties also felt natural to me, and I didn't mind taking the time to make rich ViewModel objects that had methods attached to them representing actions, and "ko.computed"s when I had more complex scenarios in which I wanted to watch for (or perform) an update.<p>However, our frontend guys hated it, and I can understand why they feel that way (though I disagree with them on many of these points, and would like to win them over). For them:<p>1) "We're moving backwards." It's a dramatically different approach that feels counterintuitive - in fact, for frontend developers who've been told their entire career to never put event handlers on the attributes of an element itself, it feels like a step backward evolutionarily. It feels, to them, like you might as well be going back to "onclick=''" bindings.<p>2) "More upfront work." It's a more upfront work to create and maintain solid and coherent ViewModel objects, particularly when Knockout provides the tempting - but often fragile - alternative of calling "ko.mapping.fromJSON" or "ko.mapping.fromJS" that will essentially make a dumb ViewModel for you, but will also make everything observable and won't give you any of the benefits of creating your own ViewModel with reasonable business logic, computeds, etc... This not only ends up making the bindings feel messy as they start performing complex logic directly in the binding where a computed or method would do, but it reinforces that bad "onclick=" binding feeling that they hate.<p>3) "We have to surrender control of the DOM." The real killer for them is that, once the DOM is being managed by Knockout, you essentially have to give your control of the DOM over to Knockout. If you start fiddling with DOM elements with your own custom jQuery handlers instead of through custom (or built in) bindings, Knockout is going to inevitably run over your changes in unexpected ways as it itself modifies the DOM. Asking the frontend developers to make custom bindings is, unfortunately, asking for more work (and less intuitive work) than just making a jQuery binding, and thus it presents itself as a lot of additional code.<p>4) "The path for mixing 'common' ViewModels with 'page specific' ViewModels is not clear." This is one I still struggle with in trying to help find a clear path for them. Let's say that a page loads with a bunch of sections that are common to every page, and there are also page specific data and operations that need to be loaded. Knockout only lets you bind one ViewModel object to a given set of DOM elements at a time, which makes this difficult. My gut is that, if we were to create these ViewModel objects in such a way that a common "binding" Javascript block of code - run after all ViewModel objects for the page were both created and combined into a single over-arching object - existed, then they could all live together. This solution is fragile, however - that means every binding would need to be bound to some object off of that single ViewModel object, which could be prone to breakage as these models change. Essentially, bindings (or DOM elements with appropriate "with:" bindings to scope out what part of that larger ViewModel you cared about) would have to be created with this larger overall ViewModel in mind. The proposals don't sound great when I talk to people about them, and I can understand their hesitation. (if any of you have good alternatives, I'd love to hear them)<p>5) "We dislike having 'logic bindings' or 'placeholder bindings'." Frequently, the data for the ViewModel isn't actually loaded yet by the time you need to bind. The way of preventing the bindings that require that data from breaking is to have boundary bindings wrapping them, such as checking if the object is loaded or the data you want isn't null... but now you've got essentially boundary checks sitting in the DOM. They dislike those - understandably - and they dislike "with" bindings as well. It all feels like fluff that they shouldn't have to worry about, and that crowds up the view. This is another one for which I don't have a good response or alternative.<p>Anyways, Knockout definitely has both good and bad elements to it. I encourage everyone to give it a try. You may love it - as I do - despite its flaws, or you may hate it! But give it a shot, it may be a handy tool for you.