Derby.js

nodejs
nodejs-frameworks

Articles
Resources

What is Derby?

Derby is web framework for Node.

Who are the primary creators behind Derby?

Nate Smith (an ex-Googler) and Brian Noguchi are the core developers of the framework, and the founders of the stealth startup Lever.

What are the main features provided by Derby?

It features a data synchronisation library called Racer that synchronises data between browsers, servers, and the database. This is one of the few libraries to truly realise the goal of running the same code on clients and servers. This data synchronisation layer is far from simple — it even includes features to help resolve conflicts. Derby isn’t just a solution for data syncing, however. It also renders templates, and handles view bindings. Derby uses a single page application structure, so the same routes are used on both the client and the server.

The motivation behind Derby is to offer flexibility while removing the requirement for what the authors call “glue code”. If you’ve ever worked with Express, Backbone, jQuery, and Mongoose, you’ve probably found yourself writing a lot of the same code to bind things together between projects. As an alternative, Derby is both interesting and opinionated — it seems likely to appeal to a certain type of developer rather than for certain projects.

Derby capitalises on the relationship between WebSockets, server-side JavaScript, and data storage to make something extremely attractive to both server-side and client-side developers. Derby has addressed a complaint many people have when working with client-side technologies like Backbone, so I’d like to see how it gets used in the future.

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.

How is the process of creating an application compared to Rails?

Applications are created using a command-line tool, much like other popular web frameworks:

derby new dailyjs

How is the template syntax for Derby compared to mustache?

Derby’s template language may take some getting used to, but it’s very close to mustache. It also includes HTML extensions to make it easier to bind models and views without lots of client-side “glue” code:

<info:>
  <div id=info>
    <!--
      Mustache syntax is used for conditional blocks, except that the
      name need not be repeated in the closing tag or if-else blocks
    -->
    ((^connected))
      ((#canConnect))
        <!-- Leading space is removed, and trailing space is maintained -->
        Offline 
        ((#_showReconnect))&ndash; <a x-bind=click:connect>Reconnect</a>((/))
      ((^))
        Unable to reconnect &ndash; <a x-bind=click:reload>Reload</a>
      ((/))
    ((/))
  </div>

What databases are used or supported by Derby / Racer?

In terms of models, Racer uses Redis for publish/subscribe and to store a journal of transactions; MongoDB is used as the data store. Racer is currently structured so that there are database adapters, so hopefully it shouldn’t be too hard to add support for more databases. It seems like the Redis dependency is more central to the design of Racer.

How does Derby compare to Meteor?

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

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License