I can't speak for Meteor as much, but Derby's bindings support pretty much everything that Knockout and Ember can do. The big difference is how you connect the bindings to model data. Knockout has a generic API that you can pass pretty much any JSON data to. This is flexible, but you end up having to write a lot of glue code to hook it up to whatever type of model you use. Ember bindings only work with Ember models. Derby automatically knows to look in its model to bind data.
Knockout is pretty minimal and fast, Ember has not performed very well in update intensive benchmarks. From our testing so far, Derby is somewhere in the middle if you bind everything, but it has granular control of bindings so you can get it to perform about as fast as Knockout.
This is just one small part of synchronizing clients, and Derby takes care of realtime data syncing as well. Synching data with ember requires a lot of manual server implementation. In addition, Ember and Knockout don't have any way of supporting server-side rendering, while Derby automatically renders everything in both the client and on the server.
You are right that you can't partially implement OT. The way that we handle it is by keeping OT operations on defined paths so that they are separately namespaced from other kinds of updates.
AngularJS's bindings beat all 3: it works with POJOs, you don't have to write glue code, and views are augumented HTML. Not "real-time", but capable of handling that with, say, Firebase. Furthermore, its testing infrastructure is best of breed, being carefully built-in and using DI. It's incredible how often it's overlooked.
Thanks - I've been digging around through the data binding internals of these JS libs and I had indeed forgotten about Angular.
I'm comparing details on deferred updates and ease of integrating an OT-type collaboration layer. Derby's already starting to head this way and appears very promising, but I think there are subtle issues both in ShareJS and Derby's implementation. I'm curious how collaboration would work on some of these other libraries, and Angular seems to be thoughtfully architected, if somewhat large.
Yeah, it's kind of unfortunate how AngularJS seems to get mentioned relatively little when it's been evaluated by various bloggers and preferred over Backbone, Knockout, Ember, etc. It's certainly one of the frameworks I'd like to see succeed in the JS space, given its great engineering and capabilities.
Personally I'm waiting for 1.0.0 and redone documentation to come out, and then I'll dive into it.
Knockout is pretty minimal and fast, Ember has not performed very well in update intensive benchmarks. From our testing so far, Derby is somewhere in the middle if you bind everything, but it has granular control of bindings so you can get it to perform about as fast as Knockout.
This is just one small part of synchronizing clients, and Derby takes care of realtime data syncing as well. Synching data with ember requires a lot of manual server implementation. In addition, Ember and Knockout don't have any way of supporting server-side rendering, while Derby automatically renders everything in both the client and on the server.
You are right that you can't partially implement OT. The way that we handle it is by keeping OT operations on defined paths so that they are separately namespaced from other kinds of updates.