Move Over Meteor: Derby Is The Other High Speed Node.js Framework In Town

Although the company behind Meteor, a framework for building real-time JavaScript applications in vein of Google Docs, just announced a nice big $11.2 million round of funding, it's not the only game in town. In my story earlier this week I mentioned Mojito, a framework developed by Yahoo. But there's still another framework that has escaped my attention, even though it's around longer than Meteor: Derby.

Much like Meteor and Mojito, Derby is a client and server side JavaScript framework for building real-time applications. Its synchronization engine Racer can be used independent of Derby.

Nate Smith (an ex-Googler) and Brian Noguchi are the core developers of the framework, and the founders of the stealth startup Lever. "We have a stable financial base," Smith wrote on the project's Google Group. "We have a very different business model than Meteor, and we are creating a product-focused company that will continue to support the framework." Meteor, on the other hand, is being developed as the primary product of the Meteor Development Group.

From a technical standpoint, one major difference is the way the projects handle server side JavaScript. Both projects use Node.js on the server side, but Meteor uses a library called Fibers that fundamentally changes the way Node.js applications are written. By default, Node.js uses callbacks, an approach to coding that's well explained for non-programmers here. Fibers abstract callbacks away so that developers can use a more traditional style of programming. Fibers vs. callbacks has become a contentious argument in the Node.js community. Proponents of using Fibers instead of callbacks claim it's much easier to code in Node.js using Fibers. The core Node.js team claims that only a vocal minority of the community prefer Fibers. Even if that's the case, it could be that developers who don't like callbacks are simply being scared away from Node. On the other hand, I'm told that the fact that the callback model was essential to Node.js' success. There have been many attempts to run JavaScript on servers since the languages introduction in 1995, but Node.js is the first one to really take off. Many of the failed server side JavaScript projects tried to shoehorn JavaScript into more traditional programming approaches, but Node.js embraced the asynchronous nature of JavaScript.

It could be that there's room for both approaches. Tim Caswell, the resident Node.js mentor at Cloud9 IDE, concluded "Instead of teaching newcomers to never use these tools, I simply advise them to learn the basics first and then once they are comfortable with that feel free to experiment with these alternative tools."

Anyway, it's not a zero sum game, but one thing that will determine the success of these projects is community adoption. As Matt Asay points out, you can't buy a community with VC cash. It's early days for both communities. Meteor has a few more contributors than Derby but both projects have attracted a few contributors from outside the sponsor companies. Both have small but active mailing lists.