Meteor revisited

[Tyler Renelle]

(Disclaimer: I don't mean for this to seem dissenting, neither do I mean to catalyze the Derby developers - but to discuss points important for evaluation.)

Back in the day when I chose Derby over Meteor, the battle was anyone's game. Meteor has always had a larger following (4k|330 follows|forks respectively) than Derby (1k|50); however, the big Derby incentive was it seemed to follow more closely community standards. Derby uses NPM, Meteor has it's own packaging. Derby deploys to standard hosting, Meteor has it's own cloud. Furthermore, Derby was built by the makers of EveryAuth - so with Authentication a future milestone of both frameworks, Derby seemed the most likely candidate.

Recently Meteor released Authentication. This includes Facebook & Google login. This shook my decision a bit (I already have a Derby app built, waiting on auth before I promote), so after a discussion in #derbyjs here are some points to consider in comparing the two frameworks. 

• Meteor Pros
• Now has Auth
• $9M funding
  
• Huge following (4k|330 follows|forks)
• Direct Mongo access (1-to-1 function mapping. You don't have to learn an ORM/API, and you can do all the stuff you're used to in Mongo)
• Meteor Cons
• "Walled Garden" - own packaging, hosting, modules - stricter limitations that Derby
• No ORM/API for database - worse for conflict resolution / other-db providers. Any other thing worth noting here?
• Derby Pros
• Better support for hosting & NPM modules - less limiting in general than Meteor
• Conflict resolution with Racer
• It seems to me: better code-sharing?
• Derby Cons
• Smaller following
• Small developer network. Nate & Brian are busy dudes - incredibly bang-up developers who have have delivered impossibly given the circumstances, but it's hard to compete with $9m funding
• No authentication.

I may be wrong on many of these points, and I have yet to even use Meteor. Me and some of the IRC guys decided we would take it for a spin & report back with what we think, but just thought it would be useful to re-open the conversation to hear what others may have experienced.  Here are some more discussions on the topic:

• http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/
  
• http://stackoverflow.com/questions/10374113/meteor-vs-derbyjs
  
• https://groups.google.com/forum/?fromgroups#!searchin/derbyjs/meteor/derbyjs/pvtbLullSn4/Ch9j6LkR0cUJ
  

[Tyler Renelle]

On the followers issue: critical mass is an important point. The more followers a project has (especially in this early phase of Node + Socket frameworks), the faster it attracts followers. A framework's following is incredibly important: more followers = more developers (and funding in some capacity) = more accelerated bug-fixing & functionality development. Luckily, Derby is no peewee in Node frameworks, 1k followers is huge for it's arena. But followers, forks, & press is something to keep an eye on.

[Nate Smith]

Howdy all,

First of all, we are friends with the Meteor team and we have learned a lot from each other. We think having multiple projects developing related ideas is good for the ecosystem as a whole.

I just wanted to clarify that we did add initial support for auth in the release a week ago (0.3.12). It isn't well documented yet, and an example is still forthcoming. We'll be getting to this shortly.

We have a stable financial base. We have a very different business model than Meteor, and we are creating a product-focused company that will continue to support the framework.

We agree that critical mass is important, and we will do a larger push when it makes sense to do so. We already have a pretty good amount of interest despite not yet focusing on marketing the framework more broadly.

Other than the licensing changes in Meteor, the comparison blog post I wrote is still pretty accurate. It's all free software, so dig in and use what you like!

Best,

Nate

[Carl-Johan Blomqvist]

To summarize some of my thoughts I wrote about on IRC after this post was posted:

- With both Meteor and Derby being so similar, I believe it to be fairly simple to port from one to the other if one really needs to switch. The template systems are fairly similar (most JS template systems are?) and of course, any HTML/CSS can be re-used. They both work with MongoDB at the moment, which means any DB design will most likely work equally well for both frameworks.

- We can all do our fair share to help Nate and Brian out by helping out as much as possible in any way possible. This includes helping out with the community, ie. helping people out on IRC, answer to questions on Google Groups, writing blog tutorials, helping out with writing documentation, writing good re-usable components, etcetera. It might seem like this doesn't contribute to the speed of development of Derby/Racer - but on the contrary this will do two things: A) Make Nate and Brian have more time to contribute to the source (because they don't have to deal with the community as much) B) Bring more people on board the Derby-train, and thus get the ball rolling faster.

- Authentication: Nate answered that one and obviously I was/am simply not getting it at the moment. Still a lot to learn!

What I think will be the two most important aspects for Derby's chance of survival (and long-term possible edge and success) against Meteor (and in general) are:

- How well it'll keeps up with Meteor in terms of functionality

- How many components/plugins there will be

Anyway, just my 5 cents.

[Trung Pham]

Add this to your list.

DerbyJS can render pages without javascript. Much more friendlier to crawler than Meteor.

The side effect of this, users will think apps built on DerbyJS are faster than Meteor. :)

[Tyler Renelle]

Update, looks like it's a lot harder to use npm modules in Meteor than I originally thought: https://gist.github.com/3190506 . First i thought "they just don't use npm, but you can if you want" - not the case. Huuuuge blow imo

On Monday, 23 July 2012 14:12:09 UTC-4, Tyler Renelle wrote: