Recs.
Updated
SpecsUpdate
Pros
Pro Works on top of Express
Sails was created to add stronger conventions to Express apps, as well as to have an ORM which could work transparently with both NoSQL and SQL databases. It works on a bit of a higher level on the development stack as Express, and the fact that it's built on top of it means that Sails does not have to deal with the most lower level stuff (such as critical performance and consistency issues across many different modules, like the Express router, cookie parser, body parser, etc...)
Pro ORM that can be plugged into any database, or even custom web service
Sails.js uses Waterline ORM at its backend which means you can store your data in any datastore that you like; all you have to do is make a change to the Waterline adapter, this will allow you to store your data in MySQL/Redis or any other kind of database.
Cons
Con Limited ORM
The Waterline ORM is a bit limited. Associations were finally added after much time and many requests. However, they are (as of 2015) still incomplete. It is not a great ORM for MongoDB. You will very likely be using native MongoDB queries throughout your code more than you might like (for example, in the event you want to use Mongo's $inc
to increment something). It's strange that Sails did not simply leverage an existing ORM for their frameworks. Many people fall into the trap of wanting to build their own despite many other existing solutions. It is only then that they realize just how much work goes into an ORM. Fortunately you can bring in whatever packages you want to use with Sails.js.
Con Incomplete, perhaps slow project development
This framework feels like something that is in perpetual beta. It was designed to solve a problem for someone and it probably did. However, it struggles a bit to keep up with Node.js breaking changes and overall the progress on the framework has slowed.
If Sails.js does not work for your needs as is, do not count on it including a feature that you might need anytime soon.
Con Slow
Sails.js adds overhead to Express.js (which it sits atop). As noted, startup is slow, but overall it is slow. It has a fairly large memory footprint due to the number of objects it has. It shouldn't be called "bloat" because you get a lot of convenient features with it and it seems like they've done a good job of keeping that feature set limited to the most common of needs.
Despite that, it is a somewhat slow framework. Which is totally fine depending on your needs. But it is important to note that at scale, it will not be the most cost efficient solution due to increased resource usage which will then be reflected in hosting costs.
Con Asset handling is messy
It's always best to serve assets statically (CDN, NAS, nginx proxy, etc.). But when you must do it through Node.js you should at least be certain to take into consideration cache busting.
Sails will adjust your layout templates by adding HTML to it for new styles and scripts. You must go through their process of handling assets to minimize this. Not bad in and of itself, but it does make it annoying to bust cache. Overall the asset management in Sails.js is a little messy and is certainly not full-featured (yet).
Con Starting up takes a lot of time
One of the major benefits that Sails has is performance. But it's not as efficient when starting up. sails lift
takes quite a lot of time to execute completely (although it is doing a lot of things behind the scenes - if you run it with the --verbose
option, you can see all the different things it's doing).
Granted, this would be perfectly fine if you had to execute sails lift
just once, but unfortunately every time that you change anything you have to stop and start lift again.