SailsJS 1.0 – Rails-like JS Framework
sailsjs.com
sailsjs.com
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".
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.
If bloat was a contest, Sails would be a winner.
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.
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
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.
As for the DB issue, I mean't show how you can connect to a DB in the docs
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]
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.
[1] https://www.youtube.com/playlist?list=PLF8BRFFRWv9VkafkA4Jtg...
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.
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.)
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. :)
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.)
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. :)
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'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.
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 was relieved when I had the goahead to mothball that project and build a new MVP using plain Express and Knex.
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.
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?
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.
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.
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.
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 know Laravel is a single dev project right?
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.
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.
That criticism is pretty dated now that JS has async/await. Given that you understand promises, async code has become trivial.
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.
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?
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.
That said, this is probably still the best nodejs framework. It's one of the few that support relational databases.
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!
[0] https://kev.inburke.com/kevin/dont-use-sails-or-waterline/
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.
If you’re starting out just ditch the ORM altogether.
Sails is just plain express so if you need to piece it apart at some point in the future it’s not too hard.
That said Sails is great for bootstrapping a reasonably secure and functioning app in short amount of time.
SailsJS was nice when I used it, but seemed clunky. I left it when all the drama went down with core, and haven't looked back.
https://sailsjs.com/documentation/concepts/extending-sails/h...
> 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.