Our take on Derby vs. Meteor(blog.derbyjs.com)
blog.derbyjs.com
Our take on Derby vs. Meteor
http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/
8 comments
Trying derby.js out now. Just so that you know you can write in Javascript and/or Coffeescript but the internal code and the examples are written in Coffeescript.
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.
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.
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.
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.
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.
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.
Very clean code and great approach to app development.
Looks like a lenghty review.
Why do all node.js based frameworks prefer nosql? And where are the discussion about automated testing and continuous integration/deployment?
I'd like to see a framework that support traditional RDBMS and makes testing in both server and clinet side easier.
Rails has set the bar higher...
Why do all node.js based frameworks prefer nosql? And where are the discussion about automated testing and continuous integration/deployment?
I'd like to see a framework that support traditional RDBMS and makes testing in both server and clinet side easier.
Rails has set the bar higher...
The reason we use a document based datastore is that it is easier to think about conflict resolution, and it maps more easily into how JavaScript represents data in the browser. It is common for large-scale eventually consistent systems to use document based stores instead of RDBMS.
We also are big fans of testing, and we will have a better answer to how testing can be done. We currently use Mocha, which is a great test runner for the server and the browser. All of our frameworks are still quickly iterating and adding important features like this.
We also are big fans of testing, and we will have a better answer to how testing can be done. We currently use Mocha, which is a great test runner for the server and the browser. All of our frameworks are still quickly iterating and adding important features like this.
Typically testing client side JS is tricky thus a combination of patterns or good separation is a good enough solution (see GWT MVP pattern).
Also; in the early days "the" node.js mysql client library was blocking, so everyone just forgot about using mysql.
> Why do all node.js based frameworks prefer nosql?
I'll venture that its because in javascript (among other languages) its more direct to 'query' generic data objects: hash.filter(), array.indexOf(), etc. Thereby pulling JSON from key-value stores is a simple catch-all that avoids dealing with SQL, schemas, and ORMs.
I'll venture that its because in javascript (among other languages) its more direct to 'query' generic data objects: hash.filter(), array.indexOf(), etc. Thereby pulling JSON from key-value stores is a simple catch-all that avoids dealing with SQL, schemas, and ORMs.
In addition to the other answers you've gotten (which are right), I think the real answer is JSON. I mean, JSON stands for "JavaScript Object Notation" (I think), but it means that your query results are effectively mapped to objects immediately.
Mongo especially returns JSON as its results, so it's usually the first choice for JS-based frameworks, for better or worse.
Mongo especially returns JSON as its results, so it's usually the first choice for JS-based frameworks, for better or worse.
> Mongo especially returns JSON as its results, so it's usually the first choice for JS-based frameworks, for better or worse.
Nitpicky, but it actually returns BSON, which is based on JSON but has more data types.
Nitpicky, but it actually returns BSON, which is based on JSON but has more data types.
No. Data is stored in BSON, transfered in BSON but when in javascript it's JSON.
I just tried the TODO app from the Derby home page and it is just doing xhr polling. I tested on Chrome and Safari.
The Metor and Firebase demos used both websockets.
The Metor and Firebase demos used both websockets.
You can turn on websockets with Derby, as it uses socket.io underneath.
Thank for clarifying. You should enable it, to demonstrate the cababilities of your framwork.
For high load push driven apps, websockets are a must. I understand that fallbacks are needed for users behind proxies etc. But if the infrastructure supports websockets, they must be used.
For high load push driven apps, websockets are a must. I understand that fallbacks are needed for users behind proxies etc. But if the infrastructure supports websockets, they must be used.
It's great to have a liberally licensed alternative to Meteor and Firebase. Many thanks for that.
What I have taken from the article:
1. Derby is done by competent people 2. They support server and client code sharing 3. MIT license 4. NPM instead of proprietary packaging
I especially like 2). It was one of the killer features of Appjet which had code sections like: /* appjet:server /, / appjet:client /, / appjet:both */ You can guess what "both" did. Appjet was miles ahead for its time. I am sure David will take care of that part at Meteor's.
Last but not least, I don't like the name Derby. It is already used by a popular Java SQL database.
What I have taken from the article:
1. Derby is done by competent people 2. They support server and client code sharing 3. MIT license 4. NPM instead of proprietary packaging
I especially like 2). It was one of the killer features of Appjet which had code sections like: /* appjet:server /, / appjet:client /, / appjet:both */ You can guess what "both" did. Appjet was miles ahead for its time. I am sure David will take care of that part at Meteor's.
Last but not least, I don't like the name Derby. It is already used by a popular Java SQL database.
Agree on the name. I'm not even sure how to pronounce derby. I have heard it pronounced both "darby" and "derby", with the former being the more traditional, "correct" pronunciation. Kind of like how you are to pronounce grand prix as "gron pree" instead of phonetically. I don't know if it's best to be "correct" or to "dumb it down" to fit in with your peers.
Can we please start talking seriously about security around these frameworks. Exposing your DB API directly to the client is opening yourself to the equivalent of "rm -rf /" or "DELETE * FROM table".
I honestly believe that most people ignore that question because they can't convince themselves that someone who can design something like Meteor would create such an obvious security hole.
Edit: If you downvote, please elaborate what I am missing. I really would like to know.
Edit: If you downvote, please elaborate what I am missing. I really would like to know.
Firebase may have major security problems; they plan on having everything client side, and have given a vague "uh, sure, we've got plans - we'll fix it all with ACLs!" answer, which isn't filling a lot of people with confidence. But they seem like cool guys, and they'll probably figure it out.
Meteor and (I believe) Derby simply don't have this this security issue; it's obvious from the design that they don't, it's a major selling point on Meteor's website that they won't, and the Meteor dev's have explained it in detail. They've even explicitly stated what was already pretty damn clear: There is no ability to drop a database (or similar) from a Meteor client.
In short, Meteor and Derby are both client/server frameworks where the security, validation, and authentication lives on the sever; that is a very well proven design (inasmuch as it's the same used in, you know, every webapp on the planet). And contrary to the parents comment, they DO NOT EXPOSE THEIR DATABASE API TO THE CLIENT.
So the reason people are ignoring the question (and downvoting you) is that you are talking about Meteor (and Derby), and those concerns obviously do not apply. If you want to argue about Firebase's security, you should feel free, but this isn't really the place to do it. :)
Meteor and (I believe) Derby simply don't have this this security issue; it's obvious from the design that they don't, it's a major selling point on Meteor's website that they won't, and the Meteor dev's have explained it in detail. They've even explicitly stated what was already pretty damn clear: There is no ability to drop a database (or similar) from a Meteor client.
In short, Meteor and Derby are both client/server frameworks where the security, validation, and authentication lives on the sever; that is a very well proven design (inasmuch as it's the same used in, you know, every webapp on the planet). And contrary to the parents comment, they DO NOT EXPOSE THEIR DATABASE API TO THE CLIENT.
So the reason people are ignoring the question (and downvoting you) is that you are talking about Meteor (and Derby), and those concerns obviously do not apply. If you want to argue about Firebase's security, you should feel free, but this isn't really the place to do it. :)
I havent claimed that they created an obvious security hole.
I gave the answer why most people dont ask that question while clearly refraining from stating an opinion on the matter, simply because i'm no security expert who can judge if introducing such an api creates additional vulnerabilities even with server side checks(not obvious).
I gave the answer why most people dont ask that question while clearly refraining from stating an opinion on the matter, simply because i'm no security expert who can judge if introducing such an api creates additional vulnerabilities even with server side checks(not obvious).
We did yesterday: http://news.ycombinator.com/item?id=3839871
Hasn't this been discussed to death?
All these frameworks are alpha and there's a range of trivial approaches to authorization, they're just not implemented yet.
All these frameworks are alpha and there's a range of trivial approaches to authorization, they're just not implemented yet.
Indeed, saying that something is "just not implemented yet" and "trivial" in the context of security makes the discussion itself irrelevant.
I didn't know about Derby, thanks for sharing.
I won't even try Meteor, they screwed it up with the license.
I won't even try Meteor, they screwed it up with the license.
Definitely Meteor is out of question given the license. I'm happy that Derby and SpaceMagic are viable MIT-licensed alternatives available today.