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 technologies like Java, or Ruby, or Node.js. A "back-end web" framework helps you do things like build APIs, serve HTML files, and handle hundreds of thousands of simultaneous users. Sails is "that kind" of web framework.
Sails accomplishes many of the same goals as other MVC web application frameworks, using many of the same methodologies. This was done on purpose. A consistent approach makes developing apps more predictable and efficient for everybody involved.
Imagine starting a new job at a company building a Sails app (or imagine starting the company, if that's your thing.) If anyone on your team has worked with frameworks like Zend, Laravel, CodeIgniter, Cake, Grails, Django, ASP.NET MVC, or Rails, Sails will feel pretty familiar. Not only that, but they can look at a Sails project and know, generally, how to code up the basic patterns they've implemented over and over again in the past; whether their background is in PHP, Ruby, Java, C#, or Node.js. What about your second app, or your third? Each time you create a new Sails app, you start with a sane, familiar boilerplate that makes you more productive. In many cases, you'll even be able to recycle some of your backend code.
Sails didn't invent this concept-- it's been around for years. Even before the phrase "Convention over Configuration" (or CoC) was popularized by Ruby on Rails, it was a core tenet of the JavaBeans specification and in many ways, a natural lashback against the extremely verbose XML configuration common in traditional Java web frameworks of the late '90s and early 2000s.
The days of forcing a one-size-fits-all approach to development are over. We need tools that allow us to pick and choose the components that fit our requirements. In fact, it’s just plain lazy to create things any other way. Sails’s approach is to loosely couple components so that they can be added or subtracted from your app at will.
Node at its core has created a “can do” culture eager to experiment and make things work. Sails embraces this attitude and strives to deliver tools that work around you. The level of automation or magic you want in Sails is directly tied to the time you have for a project and your experience working with Node. Sails is flexible enough to allow you to explore and create when you have the time but also provides automation when you don’t.
Sails accomplishes this loose coupling using plain-old require. No magic, other than the time to craft components that can be part of the whole but don’t need to be present in order for the whole to work. For example, controllers, models, and configuration files are just Node modules. Sails uses some convention to help. Sails picks up on the name UserController.js in the Controllers folder to deduce that this is indeed a user controller. Another example involves policies. So policies allow you to have a bit of code that executes on controller or specific controller action. The cool part is that the configuration file that connects the policy with the controller/action are separate. That means you can write a bunch of different policies and they are completely portable between Sails apps. You can decide later which controller/actions you want to apply them to.
Sails core consists of twenty different hooks: modules that modify the server runtime, adding middleware, binding route listeners, or otherwise attaching additional capabilities to the framework. This gives you access to override or disable every component and configuration parameter in Sails. These hooks are loaded at run-time when Sails starts. You even have the ability to have one-time configuration for your hook itself. This is actually one of the key differentiators between hooks and services.
Another example of loose coupling is configuration files. Need some configuration to be available for your project? No problem. Create a file in the config folder that uses the common module.exports pattern and everything in that module is available for you from the sails global object.
Almost every component of Sails can either be omitted, overwritten, or extended. For example, Sails has a group of tools called blueprints. These blueprints make it really easy to get a project up and running with regard to routes and CRUD operations. But suppose you want to use the read, update, and delete operations but the create action needs some tender loving care. No problem, just build a create action and the other CRUD operations keep working. Your custom action subs in for the blueprint action. It’s just that simple.