It seems that among the developer community, there exist multiple misconceptions regarding KnockoutJS. This is particularly true for developers who are not familiar with the MVVM pattern or declarative style followed by Knockout. This posts aims to clarify some of these misconceptions.
I was particularly motivated to write this post after this discussion at Stackoverflow.
1. KnockoutJS is tied to specific server side back-ends.
This mainly stems from the similarities of the declarative binding style used in KO with the WPF declarative bindings. Since I do not work with Microsoft technologies, I can not really assert if the WPF declarative binding style was indeed an inspiration behind KO, however I would like to highlight that KO is strictly a client side library and an ASP.net backend (or any specific server side backend for that matter) is not mandatory. In fact KO will work happily with no server-side code at all. I strongly recommend people to checkout the basic examples presented in the site using jsfiddle and convince yourself that this is indeed the case.
2. KnockoutJS has hard-wired dependency on jQuery and jQuery-templating plugin.
Again this is absolutely incorrect. The core functionality provided by KO is framework agonistic. And as far as templating is concerned integrating of third party templating engines is not very difficult. Since KO is open source you can probably find support for your favourite templating engine already available. For example the ko.mustache extension by Marcin Wtorkowski adds support for mustache templating engine.
3. Because of the level of abstraction offered by declarative bindings, KnockoutJS is difficult to debug.
While it is true that KO hides away the boiler plate code for data synchronization and the users are concerned with declaring the bindings in attributes, when things go wrong (either at your end or if you happen to discover a bug in the library) you will have to dig into the layers of abstraction. Fortunately in case of KO, the abstractions are not very convoluted and a basic understanding of the binding management lifecycle makes debugging pretty easy. KO source code is well written and not very difficult to understand, although that certainly is a subjective opinion.
I plan to highlight some guidelines for debugging KO applications in a future post.
4. It is difficult to properly test a KnockoutJS application.
Also, with a basic understanding of KO handlers, the bindingHandlers can be mocked, providing a greater control to the developer.
A good example for this functionality can be a grid. The basic HTML page served by the server can contain a simple HTML table with support for traditional links for pagination. Then you can create your view models from the data present in the table ( or ajax if a bit of redundant data load does not matter for you) and utilize KO for interactive bindings.
6. Although simple attribute-binding works well, designing complex interactive UI results in cluttered code.
Again code organization is something that KO does not enforce upon you. A very nice way to make to code modular and easy to understand is to use custom bindings. Custom bindings are not something to be used as a last resort . Creating them is easy and utilizing them you can write very succinct code that is easily understandable and manageable. Infact properly using custom bindings can significantly improve performance as compared to several data-bind attributes for same property across several adjacent DOM nodes.
7. Doing anything serious using KnockoutJS requires verbose inline scripts.
This is also incorrect. Please read the above paragraph on properly using dynamic objects and custom bindings.
Yes code like
The item is <span data-bind="text: price() > 50 ? 'expensive' : 'affordable'"></span> today.
8. KnockoutJS does not offer a multitude of widgets.
This is absolutely correct. But KO noway advertises the same. It is essentially a data-binding library that does one thing and does it well. It is not a complete application SDK or UI framework.
9. Integrating KnockoutJS with a restful backend is difficult.
As I previously pointed out, KO does not abstract out client server interaction. In fact the management of your Model layer is left almost entirely to you. Having said that, if your restful backend makes data available as json, the backbone mapping plugin makes it trivial to sync server data with view models.
If the structure of the data fetched from sever differs significantly from the way view models are organized, then you anyway have to write code for transforming the code.
10. Using libraries like KnockoutJS have serious negative impact on SEO.
If you follow the guidelines presented above on graceful degradation then there is no reason why this should happen.
Even if you are not concerned about graceful degradation, and your application is heavily dependent on Ajax based content fetching, These guidelines from Google, can make your website crawlable.
I sincerely hope that this post was successful in removing many of the common misconceptions regarding KnockoutJS and I also hope that you will be able to appreciate the power of this fantastic library. Please leave your suggestions and opinions in the comments. Also if you have been working on a project that enhances or extends the capabilities of KnockoutJS please feel free to drop in a link.