

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

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

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

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

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

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

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

~~~
Roritharr
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).

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

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

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

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

------
js4all
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
You can turn on websockets with Derby, as it uses socket.io underneath.

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

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

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

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

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

