lhorie's comment still applies here: Mithril.js does more than this library, and it weigths 10 times less, minified and gzipped (~5KB vs ~50KB, with dependencies).
The implementation was written by JP Monette, but it has been refactored several times by Leo Horie (the author of Mithril). Looking at the revision history should give you an idea of the various ways to use the framework.
The current version relies heavily on viewmodels, to the point of making the controller virtual.
Note that the benchmark sometimes returns NANs. It is happens when the todo count doesn't match the expected amount (it's hard to correctly benchmark async code). At the moment, Quiescent consistently NANs out in Chrome, and so do Mithril and Mercury in Safari, but only occasionally.
It is due to the test harness, not to the frameworks or the TodoMVC implementation. ==> Uncheck Quiescent when testing with Chrome, and re-run the benchmark if you get NANs in Safari.
Also, I looked at your mithril link and even though it's a smaller file size, the framework does way more than just databinding, which seems to be the only thing way.js does.
I think you need to look at the way.bundle.js for the version with dependencies as it relies on jquery.js, underscore.js, underscore.json.js, js2form.js, and form2js.js
I recently looked into React and Knockout at work, as previously we had been using JQuery for all frontend stuff. I'm not much of a frontend developer, but I found things to like about both React and KO. We aren't making single page apps, but we do need to create more rich user interfaces in the browser. I spent a week exploring both, creating two different UIs in each.
For environments where you don't have dedicated frontend people, I think Knockout is more approachable. I very much like the flow based programming ideas behind React, but in the end I think the need to either learn/implement the Flux architecture or having to follow chains of Javascript callbacks really dissuaded my coworkers from supporting it.
KO has a more familiar template-like approach. And now that the latest version also offers components, I like that I can use templates where they work and switch to components when necessary, which should eliminate some of the boilerplate I faced in React. I'm very excited to try out the new KO features, and I'm always surprised to not see much mention of KO in front end discussions at HN.
That being said, while working with KO there were times where I created bugs that would have been impossible or difficult to create with React. But I think for a team of backend developers that don't do much frontend work and who aren't that familiar with functional programming, React (whether callback property style or using Flux) is too much of a jump. For personal projects I'm interested in trying out React+Flux, though.
I absolutely adore KnockoutJS, it's completely changed the way I write JS (I'm not a huge fan of or user of javascript) and 3.2 has added component support (with templates) which for me is a huge bonus as I was doing something similar manually.
I love knockout as well, however, I would love to see something like this added. Not having to declare all bindings and just auto bind to a form would be pretty useful for small stuff like single page forms.
I think AngularJS has a very strong 2-way databinding offering (with its many directives and implicit data-change detection).
It is actually possible to just use the databinding features of AngularJS without all the framework stuff. Just need a few lines of Javascript to get yourself a scope.
An alternative to declaring bindings in HTML is to generate the forms with javascript and bind the data with d3js. 2-way binding should be achievable with d3's support for event handlers. That should also provide more flexibility as you can always drop down to DOM APIS or include other Javascript-based form controls.