Node.js Frameworks Comparison

The Node crowd is pretty DIY, so many Node developers eschew using frameworks beyond Express. Express gives you the most control, but requires the most development overhead. You have to setup and tie together everything all by yourself - and there is a lot of stuff to tie together. Furthermore, getting everything to play nicely with eachother is much more painful than you'd think:

  • Module version compatibilities
  • Boilerplate code
  • Authentication
  • Database setup
  • CSS & Javascript compiling (Coffeescript, LESS, Stylus, etc) and minification
  • Socket.io
  • And much more

Frameworks will tie everything together for you, and will ensure each piece fits the equation properly - so I recommend using a framework if you want to hit the ground running with the least amount of hassle. Conversely, I recommend choosing Express if you're savvy and want maximal control, or (as we'll see) you want cross-platform code (including mobile).

There will be countless such comparisons, each picking different frameworks. These are my top picks based on (1) my own experience using the frameworks, and (2) press / following / Github stars and forks - which specifically may be a naive approach, so take these results with a grain of salt.

This page has been translated into Spanish language by Maria Ramos from Webhostinghub.com.

Derby

Website | Github

MVC framework making it easy to write realtime, collaborative applications that run in both Node.js and browsers.

The first thing to realize about Node.js frameworks is that you're not necessarily looking for an MVC. Node.js enables isomorphic javascript design which unlocks a slew of different MV* framework patterns. Click those links if that confuses you, but the short of it is that a good Node.js framework has Model/view bindings on the client, subscription to database changes from the server (PubSub), and Javscript code-sharing between the client and the server. Derby and Meteor are the most popular frameworks of this sort, and Derby is the one which follows the most rules (though Meteor is more popular). I present my favorite Node framework, and the framework I used to build HabitRPG: Derby.

  • Components: Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB, Mocha
  • Pros
    • Real-time (Socket.IO + Redis PubSub)
      • Model/View bindings for syncing data
      • Includes conflict resolution via Racer
    • Uses Express, so can write REST
    • Great client/server code-sharing
    • ORM (aka, Models)
    • Maintained by the creators of Everyauth & Mongoose-Auth
    • Well documented
    • Gaining popularity very fast
    • Very good underlying architecture
  • Cons
    • Small following, little publicity, few contributors
    • Slow development, stale issue queues and pull-requests
    • Currently has scalability issues being ironed out.

Meteor

Website | Github

Meteor is an open-source platform for building top-quality web apps in a fraction of the time, whether you're an expert developer or just getting started.

  • Pros
    • End-to-end framework, everything you need
      • Including hosting!
    • Real-time (Socket.IO + Redis PubSub)
      • Model/View bindings for syncing data
    • Huge following (4k|330 follows|forks) - most popular framework on the list
    • $9M funding
    • 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)
  • Cons
    • Doesn't use NPM!
      • You can install some npm packages, and Meteor itself uses some (like sockjs)
      • However, you can't install all - you have to make sure the package plays well with fibers on the server, which might require forking the project
    • No server-side rendering - can't write REST apps.
    • Doesn't follow the Node.js community standards & best practices besides
      See http://nodeup.com/fourteen for more discussion
    • "Walled Garden" - own packaging, hosting, modules - stricter limitations that Derby

SocketStream

Website | Github

SocketStream 0.3 is a fast, modular Node.js web frameworkdedicated to building realtime single-page apps

  • Pros
    • Real-time
      • But not via model/view bindings - more a Socket.io wrapper which helps RPCs
    • Extremely popular
    • Modular integration with client frameworks (backbone, ember, etc)
    • Not end-to-end framework
      • You're not at the whim of their assumptions, can use your own modules (templating languages, backbone, non-mongo db, etc)
      • You depend less on the maturity of SS as a framework, so you're less likely to be hindered
  • Cons
    • Not end-to-end framework
      • Doesn't have models / db-integration, you'll have to figure that out
      • Obviously therefore, no Model/View bindings
      • Generally DIY - you'll have to write a lot more code than with Meteor/Derby
    • So-so documentation

FlatIron

Website | Github

No one agrees on frameworks. It's difficult to get consensus on how much or how little a framework should do. Flatiron's approach is to package simple to use yet full featured components and let developers subtract or add what they want.

  • Pros
    • Each component is a decoupled, modular, swappable framework. The main point people give when choosing Express over a "monolithic" framework is that Express makes no assumptions, and gives them maximum flexibility. Flatiron completely nailed this point by providing robust frameworks which can be completely swapped out if you prefer a different assumption.
    • Maintained by gods in the Node community (Nodejitsu).
    • very large number of contributors. While it may not have the highest Follower/Fork count, unlike these other frameworks - just about every Forker contributes to the project. It has very high contributor activity.
  • Cons
    • Its components are made primarly for Flatiron, NIH regarding similar components already being used in Node.
    • It hasn't seemed to have picked up the user traction of these others, like Meteor. Be sure to read Marak's point on this topic though.

I haven't used FlatIron yet; however, after my research I think it would be my pick for non-realtime apps (I'd use Derby for real-time apps). The next time I need a robust server architecture, providing data for both my Backbone website & PhoneGap mobile app, I'll pick FlatIron.

TowerJS

Website | Github

Full Stack Web Framework for Node.js and the Browser.Built on top of Node's Connect and Express, modeled after Ruby on Rails. Built for the client and server from the ground up.

  • Components: MongoDB, Redis, CoffeeScript, Stylus (or LESS), jQuery, Mocha
  • Pros
    • Everything you need included, takes the decision pain out and will save you a lot of time (see http://stackoverflow.com/a/9904446/362790)
    • Rails MVC style
    • Unified Client/Server code
    • Well documented
    • If you're coming from Rails, you'll feel right at home
  • Cons
    • It follows Rails3 to the T. Modern JavaScript apps don't quite function according to this paradigm (they're more in the tune of Derby & SocketStream).
      Check out nodeup.com/seventeen (sequel to nodeup.com/fourteen) for details. Basically in Rails' day, MVC was needed for state, server-side templates, etc. Things are different now with client templates, Socket.IO (state), and more which node & HTML5 provide - so paradigms have changed. Tower's architecture is still f'ing awesome, but there's some question as to it's future in the node architectural discussions

Express

Website | Github

Express is a minimal and flexible node.js web application framework, providing a robust set of features for building single and multi-page, and hybrid web applications.

Plain-ol' express will give you the utmost control over your app. The problem with the above frameworks is that they make many assumptions in order to provide convention over configuration. This results in many incompatibilities with libraries or functionality you may require. For example, since Derby uses Socket.io to provide realtime functionality, session & authentication-handling is no simple task. As a result you can't just copy/paste the Everyauth boilerplate code into your server code and expect it to work - instead, a specialized derby-auth module had to be built.

In a nutshell, you can't do everyting you want to if you use a Framework - but you can if you use Express.

Client Frameworks

For many, this Node.js framework discussion is irrelevant because they use MV* client-side framework like Backbone.js, Angular.js, or Ember.js. When this is the case, your framework is client-heavy: most of the processing done by your application is on the client, and the server really just handles delivering the initial page and marshalling objects to peristent store via REST. One good reason to go this route is that it's easy to convert your web app to Android and iPhone via PhoneGap (Backbone.js particularly has a good track record running on mobile). In the end, your server technology is minimal and this comparison is moot - in which case, people usually just choose Express or Rails. If you're using a client framework, I recommend either using Express, or making sure the Node.js framework is compatible with the client framework (Tower and SocketStream are, Derby and Meteor are not). Here's great comparison of such frameworks, and see the slideshow below for more information on client vs server JS MVC.

Runners Up

  • Geddy (github) - "A hackable Web-app development framework similar to Merb/Rails/Pylons/Django"
    • [Pros] Very popular MVC which has been around for a long time. More robust than Express (full MVC), more minimal than most frameworks. Great developers & architecture.
    • [Cons] Targets the same domain as Express, so is incompatible with Express; therefore, you can't use Express / Connect middleware such as Everyauth or Passport.
  • Yahoo! Mojito (github) - I haven't yet assessed it. It came completely out of left field, 0 to 1000 followers in no-time. Try it, and I'll update here when I've had a chance to kick it's tires.

See my workflowy for the rest, notes on pros / cons of some underdogs and some simple boilerplates based on Express.

Resources

For more discussion on the topic, see

AttachmentSize
Framework Flowchart.jpg94.22 KB