I'm seeing a lot of "I haven't used it but..." in this thread. As someone who's actually been using Sails consistently since v0.10, I can easily say that it's without a doubt my favorite node framework.

I use it because I can go from idea to functional prototype in just a few hours. I don't need to spend a bunch of time deciding how to best structure my projects because it's obvious where things go.

When I have to work on a product that wasn't built on Sails, it's either a complete mess or it's clean but only because they've burned a ton of development time creating many of the same abstractions that Sails comes with out of the box.

I'll admit, the ORM hasn't always been great when you need to integrate with an existing data store. It's absolutely perfect for simple CRUD apps though and you always have the option to run native queries.

The only other semi-valid complaint I'm seeing is that the docs are bad. Well, they've been bad in the past. The new docs for v1 are loads better. I've referenced them quite a bit over the last few months.

I just launched my second product this year built on Sails and I'll soon start my third. The new features in v1 are absolutely worth giving it a shot if you haven't already.

I mentioned my view (and linked to others) because there wasn't really anyone posting direct experience at the time, and I thought it might provide some context. Obviously real experience is always preferable, so thanks for sharing.

I've used Sails, and man, it was painful. When they say "Rails-like" they mean they somehow managed to adopt the worst patterns from early versions of Rails and none of the cleverness of later versions.

If bloat was a contest, Sails would be a winner.

You've obviously never used Meteor then

If you're looking for something between the minimalism of vanilla Express and the heaviness of Sails, check out a project I've been quietly building with a small team for a couple years: https://github.com/rooseveltframework/roosevelt

We don't consider it finished (or 1.0 quality) by any means, nor do we consider the API stable or fully thought out, but we think we have something here that is unique and a good balance between simplicity and features. The main emphasis is on having as low a learning curve as possible.

We're also happy to take suggestions or even better pull requests. Got many issues marked "help wanted" for anyone interested, and we do provide mentorship to people who want to contribute but have limited experience with Express or Node.js in general and want to learn as they go.

Looks interesting. Seems it might be simpler than express MVC in some ways. You might consider adding how to connect to various databases/using an ORM in the documentation.

I didn't take an in depth look at roosevelt, but it also doesn't appear to have generators (for controllers/models etc). One of the bad things about some MVC frameworks that lack generators is the copy pasta style development

There is a generator: https://github.com/rooseveltframework/generator-roosevelt

And the database issue you raised is tracked there: https://github.com/rooseveltframework/generator-roosevelt/is...

We decided against staging a database (and especially an ORM) by default, as it would make the framework a bit too opinionated, but we're certainly not against adding support for it as an off-by-default option in the generator to add in a bunch of common db configs.

Isnt that just a generator for the app itself? I'm talking about the scaffolding/generating that .NET/emberjs do when you want to do something boilerplatey.

As for the DB issue, I mean't show how you can connect to a DB in the docs

Gotcha, yeah, we consider both out of scope of the project for now. Roosevelt has no opinion on what you should do for your frontend (thus no discussion of client-side JS stuff) and no opinion on what you should do for your database (thus nothing in the docs yet). Down the road we anticipate adding docs and generator options to add the necessary boilerplate for common approaches to those things though, but it is unlikely we will ever prescribe a default when it comes to either one of those things, given that the right client-side framework (if any) for the job and the right database (if any) for the job depends heavily on what kind of app you're building.

I'm still not 100% sure you understand my comments. I wasn't suggesting you choose a frontend framework or DB for the user. Just show how to connect to a DB of their choosing. Also, if you use the yeoman generator and choose MVC you get controllers, views, models - or something along those lines, right?. So my suggestion was: if a user chooses MVC, it would be nice to be able to do something like: yo roosevelt books. And it give you a books controller, view, and model. Or something similar to that. So that each time they want to add a resource, they dont have to perform the same action (manually creating those files) over and over again. They can just use yeoman to speed up the workflow.

Yep I'm with you. I think that's in scope of this issue I mentioned before: https://github.com/rooseveltframework/generator-roosevelt/is... - we just haven't gotten to it yet.

Implied in that issue is the notion that one day it would be nice when running the generator to be able to tell it you want to opt-in to a PostgreSQL config, or MongoDB, or SQLite, as well as populate some boilerplate MVC files for some common use cases, e.g. something like books as you say, so as to have an end-to-end example to follow.

At present, if you follow the advanced mode in the generator, some of the questions you get include:

...

? Which CSS preprocessor would you like to use? LESS

? Which JS compiler would you like to use? UglifyJS

? Where should data model files be located in the app's directory structure? mvc/models

? Where should view (HTML template) files be located in the app's directory structure? mvc/views

? Where should controller (Express route) files be located in the app's directory structure? mvc/controllers

? Do you want to use a HTML templating engine? Yes

? What templating engine do you want to use? (Supply npm module name.) teddy

...

I presume down the road, some questions we could add would include:

? Do you want to include a database config? [N/y]

[if Y] ? Which database config would you like to prepopulate? [pg/mysql/mongodb/sqlite/etc as possible options]

? Would you like to prepopulate the app with some MVC examples? [Y/n]

[if Y] ? Which examples would you like to prepopulate? [todo list/books/etc as possible options]

My team used Sails for a project about 3 years ago and can confirm that your description fits the framework to a t. We were sold on the premise of a Rails-like experience running on Node, but experienced all the shortcomings you described.

I'd also add that we probably underestimated how much using a less popular framework negatively affected our pace of development. Having a large community helps a lot when you're trying to get junior devs up to speed.

I had experience trying to hunt down decent documentation because I wanted to use Sails in a class I taught. I don't use it anymore, but the tutorial videos I made are still available here: [1]. It covers the basics of getting started. Excuse the audio on the first video. I was just figuring out how to use my equipment.

[1] https://www.youtube.com/playlist?list=PLF8BRFFRWv9VkafkA4Jtg...

+1 The fact that the core developers of the ORM think that defaulting to case-insensitivity for all queries and not using indexes is OK is enough to scare me away.

It doesn't work that way in Sails 1.0; case sensitivity is adapter-specific

That's good!

Worth noting that the previous devs even started over with a psuedo-fork of Sails called Trails: https://github.com/trailsjs/trails

Nope, none of the Sails core team are affiliated with that.

> Worth noting that the previous devs even started over with a psuedo-fork of Sails called Trails: https://github.com/trailsjs/trails

Correct. A core Sails team member (Travis Webb) left Sails and started a new project to try and fix the issues they saw with the project.

> Nope, none of the Sails core team are affiliated with that.

It's true that no one currently on the Sails core team is affiliated with Trails (as far as I'm aware), but that's not what was being claimed.

That sounds like an endorsement, based on my experiences.

> top 3 node js frameworks

What HTTP server frameworks are there?

I've seen very little Rails/Spring/Django-level JS projects.

(And maybe that's because heavy frameworks are a bad idea...fair enough, but the point still stands that there doesn't seem to be a Sails competitor.)

> What HTTP server frameworks are there?

Express, Koa, Hapi, Meteor?

> I've seen very little Rails/Spring/Django-level JS projects.

The node ecosystem is still a lot less mature than for Ruby/Java/Python/whatever and, honestly, I don't think it lends itself to that type of project. For example, those heavy frameworks you mention all have very powerful ORMs, but there's honestly no ORM in the entire node.js ecosystem that is as good as the Django ORM or ActiveRecord (and I don't even particularly like them). And Sails ORM is simply a joke, which obviously undermiens any pretensions to be the node equivalent or Rails.

So as I said, I haven't used Sails, so take this with a grain of salt, but...my experience has been that there are no "heavy" Django/Rails like frameworks on node.js, and that absolutely includes SailsJS. It's not that Sails is the best of a bad lot, it's that it's just not competing in that category.

> maybe that's because heavy frameworks

I think they're good ideas in many contexts; I just think you need to move away from node to benefit from them.

> there doesn't seem to be a Sails competitor

Again, maybe Sails has improved a lot and is now awesome, but the strong impression I've got is that by your definition, Sails is definitely not a Sails competitor either. :)

Meteor is a good example.

I'd expect full-on web frameworks -- as opposed to lightweight HTTP or utility libs -- to have routing, data persistence, access control, testing facilities (e.g. DI), and templating in an integrated way.

(FYI, I like libs rather than frameworks...this is just in the interest of comparing apples to apples.)

Am I the only one that finds ORMs not that important?

Not at all, but they are a defining feature of the "heavy" frameworks being discussed. (And one of the main selling points of Sails is their rather poor ORM.)

If you're working on Python, there's a lot to recommend both Django and Flask, but if you're not interested in an ORM, it's hard to see why you'd pick Django; most of it's killer features (eg, the admin) are tightly coupled the the ORM. Django without an ORM is basically just a slower Flask with an uglier configuration, and that's really saying something!

If you don't find ORMs important, you're not alone, but you're probably not the target audience for Sails or Rails. :)

> If you don't find ORMs important, you're not alone, but you're probably not the target audience for Sails or Rails.

True. I used to use rails for my job and I never liked it. To much complexity and to much forcing you to do things a certain way. Which is not necessarily a bad thing - I dont like it.

Ive used ramaze for a very long time and Iam about to switch to hanami and/or vue.

Nodal and Feathers.

I used Sails extensively in multiple projects for a few years. This was coming from a lot of Symfony projects, and I'd hoped Sails was going to offer similar, but in NodeJS.

I'd agree with OP mostly. Documentation was sparse once you got past the basic CRUD stuff and we came across multiple strange blockers, this was then tied with the confusing Trails fork which didn't inspire confidence.

Ended up dropping down to just using Socket.io and Express more directly and skipping a lot of the Sails framework.

It was nice to use overall though, and I would look into it again, but carefully. More likely I would just use Express and then bolt on what I needed myself though.

I've looked at it, but as far as node frameworks mirroring others, I think Adonis is much nicer... (mirrors laravel a bit), though I'm more of a php/python backend w/ vue on the frontend kind of guy.