Anyone seen Meteor?

[Anthony]

http://www.meteor.com

Thoughts? Looks pretty similar to Derby.

[Nate Smith]

Hey Anthony,

Yep, we've been keeping touch with the Meteor team since last November. In a lot of ways Meteor is very similar to Derby, and we have been learning from each other. For now, our teams have decided to continue to develop in parallel, because we think that the two frameworks are different in some interesting ways.

Let us know what you like best from each framework. All of us want to create the best developer experience, so we are very excited to learn more.

Thanks!
Nate

[Anthony]

Yep, we've been keeping touch with the Meteor team since last November. In a lot of ways Meteor is very similar to Derby, and we have been learning from each other. For now, our teams have decided to continue to develop in parallel, because we think that the two frameworks are different in some interesting ways.

Cool. Haven't looked too closely at Meteor yet -- what are some ways they differ? 

Let us know what you like best from each framework. All of us want to create the best developer experience, so we are very excited to learn more.

Well, one thing I like about Derby is the MIT license. Meteor is GPL, and because much of the app code is delivered to the client, that means all app users get the app code under GPL.

Anthony

[Nick R]

Seems pretty wildly different to me.  Here's a few differences I've noticed so far:

Meteor provides access to the MongoDB API from the client side, which is awesome, but it doesn't provide any way to lock it down, which means anyone can open up their javascript console and delete all your records.  They plan to fix this by adding authorization, but for now Meteor is more of a fun toy to use only with people you trust not to mess up your data.  That makes it great for single user or small group collaborative applications.

Derby has a very different model API which is synchronized in memory on the server side, rather than via a database, and it will only passively persisted to disk... when the devs get around to writing that part.

Meteor will host your code for you!  That is pretty awesome of them I must say.  Also they have videos and exercises along with their examples, which makes it easy to lean.  Derby doesn't even tell you how to run their examples on your own box :P.  I still can't figure out how to run them =[.

Derby has nice conflict resolution and offline support, including operational transformations.  This was the main draw of it, for me.  With Meteor, you have to craft Mongo database queries in such a way that you don't end up clobbering your data, and clients automatically decide which data binding subscriptions to believe when they receive conflicting information based on which subscription was made first.

Meteor doesn't require any special syntax to do data binding.  It just binds all values by default, like Angular does.  Derby takes the Knockout approach and only binds what you tell it to.

Meteor runs every request on the server side in its own thread like traditional web servers do, while Derby does things the Node way and uses Express.

In Meteor you declare event handlers using selectors like in Backbone, while in Derby you can declare them in x-bind attributes.

I'm sure there are a lot more differences, but these are the main things I noticed when I was reading the documentation on both sites.

[Geoff Schmidt]

Good writeup -- dead on, as far as I can tell. I'm one of the Meteor devs and we're big fans of Nate and Brian, and of Derby. I'm especially interested to see what happens with Derby's approach of putting sophisticated conflict resolution functionality in the core.

The idea with Meteor is to be a "mass-market" app platform that could be used for 90% of the sites on the web, and for that 90%, make web development faster and within reach of more people. So we've tried to keep things as simple as possible, and that meant going with a write model that is basically RPCs. We have some clever ways to avoid latency, and to let you use the same API everywhere, but when it comes to how conflicts are actually resolved, we tried to stick as close as possible to the model that is currently in the heads of web developers. There's a lot of potential upside to Derby's approach (especially for offline IMO), especially if complexity can be controlled.

One other difference: Meteor is actually just a collection of packages, and you can take or leave whatever packages you want. For example, you could leave out the entire data layer, but still use Meteor's reactive HTML templating, or vice versa. You could even imagine packaging Derby for Meteor! That could be pretty cool.

FWIW, an easy hack for locking down your Meteor collections got posted to Stack Overflow:

http://stackoverflow.com/questions/10115042/how-do-you-secure-the-client-side-mongodb-api

[Nate Smith]

Thanks for the summary Nick. I wrote a blog post with more detail: http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/

[Bob Chelios]

One comparision that bugs me:

On 13 Apr., 08:52, Nick R <nickretall...@gmail.com> wrote:
> ...

> Meteor provides access to the MongoDB API from the client side, which is
> awesome, but it doesn't provide any way to lock it down, which means anyone
> can open up their javascript console and delete all your records.  They
> plan to fix this by adding authorization, but for now Meteor is more of a
> fun toy to use only with people you trust not to mess up your data.  That
> makes it great for single user or small group collaborative applications.

> ...

currently i can do the exact same thing with derby like so:
"app.view.model.set(...)" and i didnt figure out how to prevent this
yet

[James Hudon]

Bob, I don't think you can prevent that, for now. The devs of both frameworks have clearly stated that this is being worked on as we speak, though.