Hacker News Reader

Comment by pie | Hacker News Reader

I'd be curious to hear any takes on how other similar JS frameworks focused on "live" data binding (particularly Ember, also Knockout) stack up to these two newer players. Clearly Derby and Meteor strive to be more complete end-to-end solutions, but it's my understanding that this (generally speaking, and more long-term) is specifically a goal of Ember as well.

Also, the concurrency models of all the JS frameworks of this nature appear to be pretty immature at first glance. Derby is starting to attach parts of ShareJS, but I don't see much else that looks particularly promising in other frameworks. I'm not sure that you can "partially" implement OT (or mix-and-match parts of different solutions), which perplexes me about some of the code I've seen in the area, even in ShareJS.

View on HN

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.

What subtle issues do you see with sharejs (just curious, I'm in the process of porting it's OT algorithm to python).

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.

+1 for angular

Very clean code and great approach to app development.

Reply on news.ycombinator.com