I've never tried Sails, but I'll note that it has a very bad reputation in the node community for many years, with particular scorn heaped on its poor documentation, many bugs, slow development pace, and (especially) its truly bad ORM.
Now admittedly that was three years ago, much may have changed, and this release may be amazing, but I'd suggest doing some due diligence. I've run across 6+ different projects regretting their use of Sails; I've yet to run across someone celebrating their decision. The project is troubled and probably on no one's list of "top 3 node js frameworks".
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 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
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.
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
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.
> 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. :)
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.)
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.
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.
Sails was a disaster for a startup I joined 4 years ago. We spent countless hours working around it and eventually ripped it out with great pain because of an impossible upgrade path. There are so many JavaScript antipatterns and unnecessary abstractions. Everything offered by this framework would be better accomplished by cleaner, loosely coupled individual modules like Express, socket.io, node-config, and Bookshelf.
Sails made the inexcusable choice of exposing everything globally.
Waterline tries to be a single ORM for all DBs. This is not a good idea. When I used it, it made a mess of redis by leaking these weird indexes it invents to support it's paradigms. The SQL pieces do not support joins or transactions with any amount of sanity. Use sequelize.js or Bookshelf/knex instead. Waterline can't hold a candle to the stability and expressiveness of Mongoose for mongodb. And so on.
The creator of these projects is a super smart and nice guy. But the community isn't strong enough to make this framework top notch like, say express or hapi. Sails glues things together in a way that is useful for iterating quickly as a newbie, but you can't build a realtime SaaS on it.
I ripped it out of a startup too, but can't really add much to your excellent summary. I also remember bloat, stability issues, and being locked into old dependencies.
I was relieved when I had the goahead to mothball that project and build a new MVP using plain Express and Knex.
I am usually not into framework battles, and I am not a contributor/affiliated, so take this as a sincere opinion of a fullstack js/ts dev. If you are about to jump into js serverside, take the time to evaluate Nest: https://nestjs.com/. Especially if you are coming from a modern SPA (react/angular/vue) background. I find its approach far superior to any js (and non js) backend alternatives I have been so far working with.
On my most recent app, I started with Hapi but was starting to get bothered by the number of "official plugins" that did not include TypeScript typings. After waiting weeks for official Hapi v17 typings to make it into DefinitelyTyped, I gave up and switched to Nest and found it much easier to get started.
For me, the fact that it's written in TypeScript and based on Express (i.e. you can use any Express middleware) was enough to make it more compelling than other options.
Wow, I confused that with Next.js for a moment, which I turn confused with Nuxt.js. Great...
Anyway, it's great that it's written in TypeScript. I couldn't find this with a cursory glance through the docs, but how does this handle the front-end? Can it do server-side rendering, for example, or is that completely separate?
Yes naming is weirdly close to next. Nest is basically an architecture core, think of it as a way to "angularize" (2+) your express app. You can use what library better suits you for any purpose you'd need, e.g., nuxt or pug, for SSR.
Thanks for the suggestion - the framework looks great from a cursory glance. I really like the decorator patterns - I'll use it on my next side project!
I've been using Sails since version 0.10 (about 4 years from now). At the time, it was the best framework you could find in Node with an MVC pattern. We are still using it, and it works perfectly fine for us. Even Waterline, its ORM has been great (we use MongoDB), and for doing some optimization/shortcomings, it has a .native method that allows you to implement whatever you need.
I know that a lot of work have been put into this new version, including a totally new refactored Waterline, great improvements in speed and async/await support, much better code organization/style, etc. About the "lack of support", well, I know it's been slow sometimes, but, hey, it's open source, and all the work comes out the maintainers pocket (it's not backed regularly by any company).
I really want to congratulate the team for reaching 1.0. I know all the effort you put into it, and always looking after the users, trying to make it better.
I've been using Sails 1.0 in production for the past year and haven't had any problems. Excited to see this fully released!
My experience has been that Sails dramatically improves productivity and efficiency for me and my team. As for the ORM (Waterline), we primarily make CRUD apps and haven't had a single problem with it. But, in cases where you might want more fine-grained control of your query, you can always drop out of Waterline and write native queries.
Sails isn't perfect, but it provides native access to any of the components it uses, so if you ever want to drop out and work with Express and your datastore directly you can do that.
Sails is a convention-over-configuration framework, meaning if we all agree on certain conventions then we don't all have to reconfigure every time we make any app. I think that's very difficult for people that are new to the framework, because they haven't learned the conventions yet, and they are used to doing things a certain way. But if you're willing to embrace Sails' conventions there is a huge upside in productivity.
I don't usually do this, but I find both idealboy's and luislobo's comments to be somewhat suspicious. I can't for the life of me imagine that they were paid to post positively about a crappy node framework, but one of them has few previous comments, and the other's history is... odd to say the least (including a previous similar accusation).
My sincere apologies if I'm wrong about this, but my experience with Sails (and its 'culture') has been sufficiently negative that I wouldn't put it beyond its leader(s) to pay some semi-real accounts to post in favor of it. The alternative is lack of dev experience though, so maybe that's it.
I find your comments suspicious. Perhaps you’re part of a Russian campaign to sow discord in the open-source community? My sincere apologies if I'm wrong about this, but from your comment history it sure seems like it.
Either way, I prefer to encourage the fine people that contribute to our ecosystem instead of degrading their contributions. But to each their own I guess.
Yeah, I kind of expected that response. I'd say my comment history doesn't indicate anything like that. So your point is is not a very good one.
I'm happy to hear you actually like the framework. I just was truly suspicious and felt it was worth saying.
Also, I also prefer to encourage fine people who contribute, which is exactly why I raised this suspicion. If you're a contributor, I wish you'd contribute to something better, but I commend you for doing so anyways.
I started learning Adonis once, but then I noticed it attempts to copy Laravel and that it's not yet a finished copy. So I decided to investigate Laravel, liked it and stayed with it. Laracasts and its docs are great.
Maybe Adonis can keep improving and eventually get to Laravel's level, but I highly doubt it, as it is a single developer project. Also it's a risky bet to use a single dev project.
> Maybe Adonis can keep improving and eventually get to Laravel's level, but I highly doubt it, as it is a single developer project. Also it's a risky bet to use a single dev project.
You are right. Still with 41.000 github stars and thousands of users I wouldn't worry about it being discontinued if the main developer stops working on it.
I think, to Adonis's credit, they have started slowly diverge from being a Laravel clone and forge their own path going forward. It looks really nice to use, I look forward to giving it a crack.
I haven't looked at the latest release, but when I've previously looked into SailsJS I found it quite disappointing. It falls short of the awesome Rails ecosystem.
Two criticisms:
1. No database migrations. With Rails you get built-in tools to managing database migrations. If I recall correctly, their ORM used to have some absurd default behavior, something like dropping the table and creating a new one when you wanted to change something.
2. No tests. With Rails you get a fully setup testing environment.
I tried Sails about 3-4 years ago. Basically, you're taking the good from Rails (MVP code generation, relations, convention over configuration) and puts it on JS, which unfortunately it's still a nightmare to develop CRUD apps with.
Async is great for lots of things, but not for your entire app.
If you want an async-first app, JS is probably a good choice. If you want CRUD, use Rails.
Languages that aren't async by default (most of them) make async tedious when you do want it. A web application is precisely the sort of thing I want async. So it's in fact an extra step to write async code in most languages when building a web app.
For example, just firing off a few requests (database, other APIs) in a route and awaiting them. JS makes this trivial.
That may be the case but coming from using frameworks such as .net webapi/mvc or spring do I really want to write all the controller/view code by hand every time when I don't need to or are you using other generators/methods for this?
Interesting. It looks like it took a very long time for them to get to v1.0. I used SailsJS a few years ago when it was a relatively new-kid-on-the-block framework.
But if I remember correctly, the creators of SailsJS went through YCombinator program with a product called Treeline
Not sure what happened to that product, but I do remember when it was released, there was a concern about what would happen to SailsJS.
Correct me if I'm wrong, but I do believe in terms of framework on NodeJS, Express is... the most widely used and sufficient enough for Rails-like MVC?
Did anyone use both Rails and Sails and could elaborate a bit about the development process compared to Ruby On Rails?
I had a brief look at the boilerplate project sails generates supporting login and payments but I found it not as clear as Rails. But I use Rails for about 9 years now and therefore I am used to it.
The lifecycle callback methods are almost identical to Rails. Waterline is an absolutely awful ORM for database management: You have almost no granular control over joins on MySQL tables. Additionally, the third-party libraries available for Node.js are much more sparse than the Rails' ecosystem.
Having said all of this, I am still very excited to upgrade my Sails API to 1.0 and take advantage of all of the new ES6 features.
I used rails about 3 years with multiple versions, and recently started to work on Node.js. Typically pure express-based websites tend to become quite messy, at least the projects I worked on. Started a new site with Sails.js 1.0 (beta) recently. It's definitely not as solid as rails. But overall I am pleased so far, except some shortcoming, ex. the lack of out-of-the-box migration system.
I agree. The documentation feels lacking as well, though maybe it's gotten better for 1.0. There's no equivalent to the Rails Guide which was something I've taken for granted. One of the sails devs came out with a detailed book but it uses Angular 1.x as part of the examples.
That said, this is probably still the best nodejs framework. It's one of the few that support relational databases.
I owe a great deal of gratitude to the Sails team. I've built numerous projects over the last few years using Sails. Congratulations on the big 1.0! I do somewhat agree that documentation is sparse and Waterline is a hit or miss but for most things, Sails has served me very well.
The only thing that stopped me from trying this out more in the past was it not being at 1.0 yet. So definitely looking forward to giving it a go at some point
I've used sails 3 years ago on a startup that we wrote from scratch.
Don't want to be negative but it is by far the worst framework and ORM I've ever used. Strongly recommend reading this[0] before you even start fiddling with the framework.
Even tho there are 100 wrong things about it the absolute worst: ORM "migrations" work in a way that they drop the tables and and then re-create them. If you have a lot of data the table is dropped and you get Out Of Memory exception - what a great ORM!
Creator of Sails here. I’d like to set the record straight: The automigrations system is not, and was never, designed for production use. Sails/Waterline documentation explicitly and repeatedly warns against using this feature in production.
On top of that, developers are forced to accept a prompt on the terminal the first time they lift an empty new app indicating that they understand this. The only way to make the prompt go away permanently is to hard-code configuration, indicating that you understand what automigrations are designed to do.
In fact, just to be safe and prevent accidents, automigrations are forcefully disabled in production mode.
In other words, to get your production/staging app into a state where this criticism is relevant, you have to ignore console warnings, skip reading the documentation, and go out of your way to trick the framework into thinking you’re running your app in development mode.
I won’t beat a dead horse re other points in that 3-year-old blog post, except to say that, 3 years ago, some of them had merit. Those have been addressed in the Sails 1.0 release.
We have tried it a year ago and were very disappointed: it was nothing like rails and no batteries included worked as expected. Did the framework categorically improved since then?
It's similar and different at the same time. Both handle HTTP and Websockets at the same time, have different kind of adapters-hooks-pluggins to serve different needs.
Both are opinionated, but Sails is more express-like (you can create "hooks" that are basically express middleware on steroids.
> There are more than 200 community hooks for Sails.js available on NPM. Here are a few highlights:
You appear to have read this a bit too quickly. As someone linked below, there are actually over 350 community hooks. Disclaimer: I have never used Sails, know nothing about it, and have no intention to use it in the future.
Representative criticism: https://kev.inburke.com/kevin/dont-use-sails-or-waterline/
Or see the comments here: https://github.com/balderdashy/sails/issues/3429
Now admittedly that was three years ago, much may have changed, and this release may be amazing, but I'd suggest doing some due diligence. I've run across 6+ different projects regretting their use of Sails; I've yet to run across someone celebrating their decision. The project is troubled and probably on no one's list of "top 3 node js frameworks".