Our take on Derby vs. Meteor

http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/

by pie • 14 years ago

164 30 14 years ago

blog.derbyjs.com

pie2• 14 years ago

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.

nateps2• 14 years ago

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.

oluckyman• 14 years ago

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.

edwinnathaniel2• 14 years ago

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...

nateps2• 14 years ago

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.

edwinnathaniel2• 14 years ago

Typically testing client side JS is tricky thus a combination of patterns or good separation is a good enough solution (see GWT MVP pattern).

kylebrown• 14 years ago

> 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.

bmelton• 14 years ago

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.

Animus7• 14 years ago

> 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.

coenhyde2• 14 years ago

Also; in the early days "the" node.js mysql client library was blocking, so everyone just forgot about using mysql.

js4all3• 14 years ago

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.

tpryme• 14 years ago

You can turn on websockets with Derby, as it uses socket.io underneath.

js4all3• 14 years ago

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.

js4all3• 14 years ago

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.

secoif• 14 years ago

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.

harryf• 14 years ago

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".

Roritharr2• 14 years ago

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.

Lazare• 14 years ago

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. :)

moe• 14 years ago

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.

DasIch• 14 years ago

Indeed, saying that something is "just not implemented yet" and "trivial" in the context of security makes the discussion itself irrelevant.

ra• 14 years ago

We did yesterday: http://news.ycombinator.com/item?id=3839871

Jebus• 14 years ago

I didn't know about Derby, thanks for sharing.

I won't even try Meteor, they screwed it up with the license.

kolev• 14 years ago

Definitely Meteor is out of question given the license. I'm happy that Derby and SpaceMagic are viable MIT-licensed alternatives available today.

timc3• 14 years ago

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.

Our take on Derby vs. Meteor

Related Stories