Sails.js vs Meteor - What are the advantages of both?

I've been reading a lot on Nodejs and its frameworks and recently finished my first full javascript frontend (using Angularjs).

I've decided that my next pet project will be a Nodejs adventure using one of these two frameworks:

• Sails.js
• Meteor

I've read about both, but still can't quite grasp their differences and why should I choose to use one over the other. So please put on your best salesman hat, pick a framework, and sell it me.

Some features I require for my pet project are:

• Live scores
• Reddit-like threads, realtime
• Wikipedia-like page edition
• Users/Roles

I can't speak for Meteor, but I can help provide a little background on Sails because I created it.

tldr; Sails is not a panacea for all of the web's problems-- but I believe Node.js is. The goal of Sails is to provide a practical framework for developing complete, scalable, startup and enterprise-friendly applications built on node.js. I started Balderdash with the question "Can we use Node.js for everything?". Sails is the answer.

---

From our new docs:

> Sails is, of course, a web framework. But take a step back. What does that mean? Sometimes, when we refer to the "web", we mean the "front-end web." We think of concepts like web standards, or HTML 5, or CSS 3; and frameworks like Backbone, or Angular, or jQuery. Sails is not "that kind" of a web framework. Sails works great with Angular and Backbone, but you would never use Sails instead of those libraries. > > On the other hand, sometimes when we talk about "web frameworks", we mean the "back-end web." This evokes concepts like REST, or HTTP, or WebSockets; and is built on technologies like Java, or Ruby, or Node.js. A "back-end web" framework helps you do things like build APIs, interact with databases, serve HTML files, and handle hundreds of thousands of simultaneous users. Sails is "that kind" of web framework.

A couple of years ago, I made a commitment to use Node.js for everything- it was love at first sight. I built Sails on top of Express and Socket.io because they were (and still are) the most well-established Node modules for their respective use cases. The request-handling code in Sails is Express-compatible, with the additional advantage of implicit support for Socket.io.

Sails is designed to be compatible with whatever strategy you have for building your front-end(s) in Angular, Backbone, iOS/ObjC, Android/Java, or even just offering up a raw API to be used by another web service or your developer community. If you end up changing your approach (e.g. switching from Backbone to Angular) or building a new front-end entirely (e.g. building a Windows Phone native app), your Sails app will still work. As you may already know, some people call this approach a Service Oriented Architecture, or SOA (Joe McCann has a great deck on the subject.)

Along the same lines, Sails maintains other familiar conventions for building web servers-- a standard MVC structure, the ability to create clean APIs, and core modules which are open, configurable, extensible, and even swappable. This means that Sails can be customized to fit its users' needs, as low-level as is necessary.

In 2013, the framework experienced some tremendous growth in popularity, and our consulting business grew. The rest of the core maintainers and I broadened our focus on making backend development as quick and straightforward as possible. Related aspects of Sails like hooks (plugins), testing and docs have all come a long way over the last year thanks to the efforts of both our core team and the (ever-expanding) Sails community at large. There are plenty of roadmap items that we're still working on, but I believe Sails is the best option out there for stable, maintainable MVC development on Node today. The rest of the team and I are committed to its continued maintenance and feature development, and since we use it for all of our client projects, it's not going anywhere.

I am head-over-heels committed to making Sails the best web framework out there, but never at the expense of Node.js. The core team and I are relentlessly devoted to the enhancement of the Node ecosystem, and that means embracing NPM, leveraging existing Node technologies and best practices, etc. Not just because it makes more sense, but because we're Node.js developers. The motivation for all of our efforts is to make Node more accessible, not to supersede it. So, if, in some weird parallel universe, I was given a Faustian choice between converting Sails to some other language, or completely ditching Sails but still being able to use Node, I would pick the latter.

---

Additional Resources:

FAQ | Sails 101 | Original screencast | Contribution Guide | Stackoverflow

Google Group | Roadmap | IRC: #sailsjs on Freenode | Build Status

I've built a couple of projects with Meteor and haven't worked with Sails yet. So my opinion is going to be certainly biased, hopefully its helpful anyways.

Building the front-end

Meteor provides its own front-end framework called Blaze-to be included in the upcoming 0.8 release. Meteor takes care of binding data from your collections to your views. Because of this you don't have to worry about telling your views to update, they just do it.

On the other hand, Sails only provides a backend framework and you will have to bring your own front-end framework.

Unlike most Node.js frameworks Meteor is synchronous

Meteor runs in a loop and if you want to use Node.js packages you will have to do some extra work to make sure they operate properly in Meteor.

Sails seems to be a straightforward MVC Node.js framework so there shouldn't be anything too surprising when you look into it.

You should use MongoDB with Meteor

Yes you can use other databases with Meteor but they don't have anywhere near the same support as MongoDB does. Whereas with Sails, it looks like they have ORMs for a couple of databases.

Performance

For large scale applications Meteor may not perform well. There is a lot of work being done to tackle this issue and by the end of 2014 we can expect there to be scaling solutions for Meteor.

Stability

Meteor is still very fresh and has not hit 1.0 yet. You should expect some changes to be made over the next couple of releases that will break backwards compatibility. If you are getting started with it ASAP then you might want to consider using the 0.8-rc0 branch. That being said, some of the features in the pipeline are really great and will make a 1.0 version very enticing.

Final thoughts?

I like Meteor because of its idiosyncrasies. You will have to learn the Meteor way of doing things but once you start doing it, you feel like you've drunk the kool-aid. Because of the way data is bound to views the lines between the server and client are not distant. Meteor represents a paradigm shift in application architecture and if you haven't tried it yet I would recommend it.

PS Checkout the roadmap to get a feel for what is coming up.

I can only give an opinion on sails. I am an extremely experienced Javascript developer and have been building embedded set top box applications built on Javascript since the 90's.

Things that worked really well

• Getting started was great and I felt very supported by the published materials
• The learning curve was very short, and there is a healthy community behind sails
• After the initial learning it is very easy to be creative quickly

Things that could be improved

• Complex data structures are tricky to implement
• Passport.js integration was painful as there is no clean reference materials

Recommendations

• Ponzi coder has a great tutorial and It really helped me get going https://www.youtube.com/user/ponzicoder
• Knowing more about express and waterline will help when you attempt more complex data challenges

Overall I would recommend sails.

I currently use Meteor and have not used Sails.js.

Meteor has been exceedingly pleasant to work with and I think it would be an excellent choice for realtime web apps. Regarding users/roles, you can check out the integrated Accounts package and also search Atmosphere for community-contributed roles/permissions packages.

Ultimately I would recommend trying a small project with both technologies and seeing which you like better.