Express.js vs Sails.js Comparison

This is an overview comparing Node.JS frameworks including Express, Sails, HAPI and Lazo.js. Express is clearly the most popular currently version 4 at the time of this writing.   The next framework gaining popularity is Sails currently at version 0.10 with 124 code contributors since its inception in 2012.  Sails is not an independent framework on its own, because it uses Express for handling HTTP requests.  HAPI has 95 code contributors since 2011 but is mainly for building APIs on your server.   I am also mentioning Lazo.js because it was developed for SEO compliant websites and single-page applications are natively not SEO-friendly.

Express takes the most common tasks for a web server and makes them easier to use with less lines of code wrapping native Node.js functions.  Since there are cases where Express doesn’t abstract a needed function or doesn’t conform to some preferred convention, other frameworks take place.  Those other frameworks are not completely independent therefore you still have to use Express.  Since Express is already widely written about let’s focus on the other frameworks.  The possible main detractions of Express are the lack of  database abstraction and real-time socket communication.

SAILS

This is where Sails comes in.  Sails follows the “Convention over Configuration” philosophy adding value to Express in several ways.  First it wraps socket.io for managing websockets whereas in Express you have different instances of HTTP and websocket servers.  Sails also includes a command line generator to quick start your projects using a scaffolding.  The folders generated will be:

/assets (for libraries)
/public (files rendered to client-side)
/config (settings, scripts before launch, translations, policies, and routes)
/view (templates in embedded javascript format)
/api (database adapters, models, controllers, and services)

Another great benefit of Sails is concatenating and minifying CSS and JS files using Grunt.  This will improve performance for the client-side because any additional files via GET calls increase page load times.  Routes in Sails use RESTful route conventions and are also similar to AngulaJS routes.  Here’s an examples:

module.exports = {
  '/login': {
    controller: 'auth',
    action: 'login'
  }
}

The typical url route may be /:controllers/:action/:id with automatic redirection if a parameter is omitted.

The views are for html templates using embedded js (ejs) and have four types:

  1. partial – html snippets
  2. layout – html that goes outside the body such as headers and footers
  3. server-side
  4. client-side

Models are defined by attributes and associations.  They follow object-role modeling Waterline.  The data adapters are pre-configured for memory, disk, and mysql. Here’s an example of a model:

var Model = {
  attributes: {
    title: {
      type: 'STRING',
      required: true
    }
  }
}

Controllers can be generated by command line with or without these included actions:
create, destroy, like, tag. Here’s a code examples:

var CommentController = {
  create: function(req, res) {
  ...
  }
}
module.exports = CommentController;

So now that you have something to compare to besides Express, let’s go over HAPI version 7, started in late 2013.

HAPI

HAPI is a little more of the “Configuration over Convention” philosophy because it is designed for APIs but also includes features not available in Sails. These included features are:

  • input validation
  • caching
  • pre-fetching
  • auto documentation

The downside is the lack of community support, even though there are several modules available for download. Interestingly enough, HAPI cannot listen to localhost address. Here’s a code example:

var server = new hapi.Server('0.0.0.0', 8080, config);
server.route({
  method: 'GET',
  path: '/hello',
  handler: function (request, reply) {
    reply('hello world');
  }
});

LAZO

Finally another addition which is powered by HAPI is LAZO.js  This framework uses require.js, backbone, jquery and handlebars.  The reason LAZO is SEO compliant is because the routes are mapped to a URI for crawlers to index your site.

The anatomy is smaller so you only have:

/app (configuration code, css, and utilities)
/component (business logic encapsulation,
/models (data models and collections)