Knockout.js – why it’s not a framework

Many questions come up in reference to Knockout.js, and most of the time it is a developer who is new to the use of a JavaScript library such as Knockout.js who is coming from some other language and looking for what are the key tools to use.  Knockout provides developers with an easy to use two way data-binding paradigm that is rivaled by none (in my humble opinion)

Why is Knockout.js so hard to understand?  Meno’s idea of ‘The Learners Paradox’ references why this is so difficult in a new perfect way.  When Socrate’s asks Meno’s to find answers to something of which he does not yet understand, Meno’s replies that how could he seek out knowledge without the ability to know what to ask for.  

This perfect example illustrates why the Q&A style never works in computer programming.  The world of programming and computer technology is ever changing and as such it takes one more skilled than I to understand how to ask a question that has an answer for which you do not yet know of.  If you knew what the answer consisted of, and therefore knew the question to ask, why would you ask the question of others as opposed to the search engine of your choice?

The answer is that you wouldn’t.  As a self-respecting nerd, or anyone of any background, you would never ask a question of others unless you either knew the answer already and were seeking approval of your understanding of the answer, or you were too tired or lazy to look up the answer in the docs or whatever else was available at the time to you.

Knockout has the best doc’s of any JavaScript library available.  Period.  No other library or ‘framework’ keeps it as simple as Knockout.  Want to know the definitive answer?  Google it…  Boom, there it is.  Take Angular as an opposing example – When you google what you may be doing wrong in whatever portion of the code, you may get hundreds of results on how the author did it, as well as the Angular docs themselves which aren’t very definitive at all.  The Angular docs give examples of how it could be done, following the authors exact use case, and then go on into why each commenter disagrees with the OP or why the OP’s answer is wrong.  

Knockout’s area of concern is strictly related to two-way data-binding, and nothing else.  Want templating?  It’s there, but not great.  It’s there to provide the easiest way to perform the action that you intend to use without forcing you to use a specific methodology.  Want a data-library?  Then look no further than the plethora of libraries that provide such functionality.

Knockout.js is not an end-all framework or library that forces you to choose a path.  Knockout makes such an obvious choice for developers because it generally points you in the right direction.  Want to map simple objects from the server?  Use the mapping plugin.  Want to create form validation on the client?  Validation plugin…  Want to figure out how to create expert-level custom binding handlers?  Turn to, and users such as and