I don't use sails but I found the criticism of the project interesting because it has somewhere around 80 commits in 9 months.
I guess we are in a time where our tools are expected to significantly change frequently? It seems like I have a disconnect with this mentality as we're running products where stability (reliability as well as API stability) and solid documentation are more important than constant innovation. I like to see bug fixes or security patches addressed quickly, and perhaps a branch for the next major version. But if there's no major issues then I really don't need to see hundreds of commits happening every month on the current branch.
I don't know, perhaps sails is riddled with unfixed bugs? If not though, judging a project on the number of commits seems somewhat like judging it based on lines of code. Neither of those metrics necessarily indicate quality.
> I don't know, perhaps sails is riddled with unfixed bugs?
I wrote about a fair amount of unexpected behavior with Sails/Waterline. Some of these have since been fixed, some of them (Waterline defaults to dropping tables unless you have NODE_ENV=production in an env var) are deliberate decisions and hence not "fixable". https://kev.inburke.com/kevin/dont-use-sails-or-waterline/
There's a fair amount of other stuff I would hope to change and that we've just ripped out of our fork.
- If count() isn't implemented in an adapter Waterline will fetch the entire table into memory to count the number of rows.
- Sails by default creates a route for every function in a controller, which makes it easy for an attacker to bypass policies
- blueprints routinely 500 server error based on user input
- All SELECT queries on text fields call LOWER() before matching, so all of your indexes also have to match this
- There's a batch insert interface but N connections are established to insert N records... if one of the inserts fails, the behavior of the other inserts is not guaranteed
- There's a batch insert interface but N connections are established to insert N records... if one of the inserts fails, the behavior of the other inserts is not guaranteed
Whoa, that is bad. If you don't understand what a transaction is, you have no business writing a database library.
Sounds like at least a few of those are legit concerns, if not bugs.
Like I said, I don't really know much about Sails. I was just interested in the idea that ~10 commits per month would be insinuated to be an abandoned project.
Mike wrote in here, sounds like they are just busy working on Treeline. My read: doesn't help having an ex-employee / collaborator telling everyone Sails isn't supported any more. That just seems like trolling.
> Hey Cody, thanks for sharing your concern. Apologies for the lack of transparency from our end- it's coming from a place of limited resources, not deliberate opacity. Like you said, we're a small team spread across a few large projects right now; and it's part of why we've been in more of maintenance/stability mode with Sails and Waterline over the past 9 months.
> Another thing has happened too: we've become more attuned to the full lifecycle of development with a Sails app. The work we do outside of open-source has always been a huge influence on Sails-- I mean, I firmly believe the reason why the framework has helped so many other folks is that we've always focused on solving real-world problems that we have ourselves. Now that we are a product company (as opposed to being focused on services), our team has become more attuned with the experience of working w/ a Sails app over the course of months or years (as opposed to the experience of the first 2-3 months). As you might expect, maintaining our own large-scale production deployment has drawn our attention to issues like security and performance more than ever before.
I found SailsJs unfit for any projects that had even a moderately sized set of business rules. Partly due to Node's lack of threading and partly because SailsJs feature set was a weak or incomplete copy of 'real' frameworks which failed to meet needs once they had to offer anything more than an extremely light CRUD wrapper.
I agree with fideloper that it's better not to use NodeJs or any of that mess of an ecosystem for projects more complex than 'plumbing code'.
Saw this comment and it reminded me how Waterline ORM became a running joke at my office. Save yourself a headache and avoid these JS backend frameworks:
> I can chime in on Waterline since everyone keeps mentioning deep populate! The PR for the polyfill is pretty much ready to go, it's a recursive query runner that will run queries until the results are completed. This will increase the query count in sql adapters until the adapters understand how to interpret and build these join queries (nosql adapters don't have joins so those will work).
Who needs N+1 select issues when we can have recursive queries baked right into the ORM! smh
Node.js is fine. I'm currently contracting for a major company which is using Node.js in production and it's been great. I've worked on Python backends at my previous startup and I can say that Node.js faster to develop with.
Linkedin also uses Node.js and they found a 50% increase in development speeds as a result after making the switch a few years ago.
It's less of a language issue and more of a framework/ecosystem issue, which is what I think the original commenter meant. The Node.js community is much more fragmented than Python. At least when it comes to web frameworks. Everyone has their own Node framework. Old ones often end up getting deprecated and neglected. So I think that's what people are referring to when they say that Node.js is an unproductive ecosystem. You end up spending way more time on the Github issues page of your framework than you would for the frameworks of other languages (Python, Go, ...) where, for the most part, the tools just work.
I've used sails.js for many (many) projects including gameref.io, hackjob.io, and on several internal projects at my current job. I find it ideal for prototyping and small-to-medium-sized projects. I really hope it doesn't die as I love the pipelined approach it takes.
@SignMeTheHELLUp is complaining about Waterline ORM, but I'd argue that Hibernate is worse (and it's an "industry standard"). It's just a fact of life that ANY ORM will suck because it tries to build an isomorphic API over several database abstractions.
Also, come on, entire world-class companies are based on a Node.js architecture (Uber comes to mind)[1]. If you can't write solid code in Node, you're probably just a shitty programmer.
> SignMeTheHELLUp is complaining about Waterline ORM, but I'd argue that Hibernate is worse
Are you serious. Hibernate and all it's language-specific variants are actual feature-complete ORMs. Waterline falls flat as soon as you get past eager-fetching a child property. It's a toy.
I wasn't just complaining about Waterline either. Every time I had issues with Sails I had to dip into the Sails source and patch bugs out, eventually I replaced parts of Sails with libraries that actually worked. By the end of the project the only "Sails" left was the routing component...
Edit: Of the two sites you linked to, one is a splash page and the other is an aggregator that loads slowly. Neither are real-world LOB applications with complex logic underneath them.
I can write solid code on Node the same way I can on any PHP framework, but I'm experienced enough to know to look elsewhere when my requirements are complex.
> Every time I had issues with Sails I had to dip into the Sails source and patch bugs out, eventually I replaced parts of Sails with libraries that actually worked. By the end of the project the only "Sails" left was the routing component...
Would love to hear more about this - if time permits, would be a great write-up.
I linked to toy projects, I never claimed otherwise. Some people, however, use Sails.js for real business solutions.
> I wasn't just complaining about Waterline either. Every time I had issues with Sails I had to dip into the Sails source and patch bugs out, eventually I replaced parts of Sails with libraries that actually worked.
I don't even know what this means. Sails is basically just a router on top of express with grunt tying everything together. What part of sails did you have to "replace"? The i18n? Let's not be dramatic here.
But then again, your post about staying away from Node just showed how unhinged you are. I'm no language zealot, but that's just ignorant to say when world-class companies are using Node on incredible scales.
I can understand doing this from a maintainer point of view - I'll bet this gets written in a better way using the lessons learned from the first version.
Moving fast and breaking things seems par for the course in javascript land, I don't really try to keep up.
I've ended up only using NodeJS for plumbing type apps (e.g. web hook listeners calling other APIs), definitely not for full on web apps, which I've found too-easily devolve into a mess of code.
Keeping up with anything in the NodeJS community is hard - from Node/NPM itself to all the OSS projects around it. I still use it, but I do definitely make fun of how often I'm destroying the node_modules directory and npm installing "fresh" due to the weirdest errors.
My last startup was built on top of Node.js, Sequelize and Postgres, which worked fine for us.
At my current one, we are re-implementing a ton of very detailed business logic from a PHP/Cake app, while writing comprehensive functional and browser tests. We considered Sails.js but decided the framework was immature vs. Ruby on Rails.
Rails has worked great for us, and has a ludicrously evolved ecosystem, with fantastic gems available, Stack Overflow answers, and lots of other users filing and resolving Github bugs before us (most of the time).
Rails is not as trendy as Isomorphic Javascript, but Ruby is a pleasure to develop on.
The turbulence with Sails.js makes me feel even better about our choice.
Isomorphic Javascript has very little to do with trendy and mainly a function of optimizing for mobile experience e.g. reducing latency, smaller payloads which means SPA and websockets and in real world SPA needs to support SEO, FB scraper etc. so Isomorphic is the only viable real world option.
The Trails project is developing thanks to Travis Webb and team, and his reasons are described in the pull request.
The Trails README includes this intro:
"Trails is built and maintained by former members of the Sails.js core team, and offers an upgrade path from existing Sails applications, but it utilizes exactly zero lines of code from the original Sails project."
I've looked over these issues and noticed Travis is just copy/pasting the same message stating "Sails.js is no longer actively maintained". It seems like this guy has a real vendetta against Mike (the creator of Sails) and is dead set on getting all current developers of Sails libraries to either make their library trails compatible or die. This guy really doesn't like Mike and even though he has some good points on making a new framework it seems there might also be some personal issues driving this decision.
Personal or not, our entire company is devoted to making Trails the best damn backend framework for node. We don't distract ourselves with VC-funded side projects, and we don't have a automated bot that closes everyone's issues (see: SailsBot).
Our company lives off consulting around the open-source tools we build and support. That's it.
Your language puts Travis's post in the worst possible light, "vendetta", "compatible or die" etc, when in actuality, most Sails.js devs, including myself, up until this post, were unsure about the continuity of the project.
If I were to speculate, I believe this diction has less to do with Travis hating Mike and more to do with the fear of being outmoded, i.e. "We built our library on SailsJS and it would be unthinkable/very difficult to change if SailsJS was subsumed by another project"
Comments on your main library give credence to this fear, such as the one posted by the main dev just recently in the Github issues:
> Waterlock has been struggling recently because of a lack of time from the guys that maintain it. I've tried to do what I can and so have the other guys. But there hasn't been enough going on recently.
Factoring in that Waterlock has 43 open issues since 2014 that have either not been closed or given a label, I can see why there would be uncertainty over this library's future.
Eh, to me it seems like someone who is really invested in a project and would like to see as much of the current Sails user base as possible contribute to the Trails community. May be more tact could be used, but I think he's doing a good thing.
I saw this discussion because Travis paid to promote a tweet to it. I'm still not sure what would inspire a person to do such a thing, and clicked to find out why. I'm still no closer to an answer.
I used sails for multiple small to mid-size projects. IMO, there's nothing seriously wrong with sails. It's easily extendable and if you don't like anything (Waterline has no transaction etc), just replace it.
For beginners, you can still use sails to build apps and also take the project structure of sails as a good starting point for building node.js applications.
The only minor gripe I had with sails is that the "neglected" vibe it gives on github.
Otherwise, I will continue to use sails and also check out trailsjs on the side.
Readit News
I guess we are in a time where our tools are expected to significantly change frequently? It seems like I have a disconnect with this mentality as we're running products where stability (reliability as well as API stability) and solid documentation are more important than constant innovation. I like to see bug fixes or security patches addressed quickly, and perhaps a branch for the next major version. But if there's no major issues then I really don't need to see hundreds of commits happening every month on the current branch.
I don't know, perhaps sails is riddled with unfixed bugs? If not though, judging a project on the number of commits seems somewhat like judging it based on lines of code. Neither of those metrics necessarily indicate quality.
I wrote about a fair amount of unexpected behavior with Sails/Waterline. Some of these have since been fixed, some of them (Waterline defaults to dropping tables unless you have NODE_ENV=production in an env var) are deliberate decisions and hence not "fixable". https://kev.inburke.com/kevin/dont-use-sails-or-waterline/
There's a fair amount of other stuff I would hope to change and that we've just ripped out of our fork.
- If count() isn't implemented in an adapter Waterline will fetch the entire table into memory to count the number of rows.
- Sails by default creates a route for every function in a controller, which makes it easy for an attacker to bypass policies
- blueprints routinely 500 server error based on user input
- https://github.com/balderdashy/waterline/issues/1248
- All SELECT queries on text fields call LOWER() before matching, so all of your indexes also have to match this
- There's a batch insert interface but N connections are established to insert N records... if one of the inserts fails, the behavior of the other inserts is not guaranteed
After the ugly discussion at the OP's link we decided to fork Sails and Waterline and rip out all of the stuff we don't need. I wrote about that here: https://kev.inburke.com/kevin/safely-moving-a-large-shrinkwr...
Whoa, that is bad. If you don't understand what a transaction is, you have no business writing a database library.
Like I said, I don't really know much about Sails. I was just interested in the idea that ~10 commits per month would be insinuated to be an abandoned project.
https://github.com/balderdashy/sails/issues/3429
> Hey Cody, thanks for sharing your concern. Apologies for the lack of transparency from our end- it's coming from a place of limited resources, not deliberate opacity. Like you said, we're a small team spread across a few large projects right now; and it's part of why we've been in more of maintenance/stability mode with Sails and Waterline over the past 9 months.
> Another thing has happened too: we've become more attuned to the full lifecycle of development with a Sails app. The work we do outside of open-source has always been a huge influence on Sails-- I mean, I firmly believe the reason why the framework has helped so many other folks is that we've always focused on solving real-world problems that we have ourselves. Now that we are a product company (as opposed to being focused on services), our team has become more attuned with the experience of working w/ a Sails app over the course of months or years (as opposed to the experience of the first 2-3 months). As you might expect, maintaining our own large-scale production deployment has drawn our attention to issues like security and performance more than ever before.
I agree with fideloper that it's better not to use NodeJs or any of that mess of an ecosystem for projects more complex than 'plumbing code'.
Saw this comment and it reminded me how Waterline ORM became a running joke at my office. Save yourself a headache and avoid these JS backend frameworks:
> I can chime in on Waterline since everyone keeps mentioning deep populate! The PR for the polyfill is pretty much ready to go, it's a recursive query runner that will run queries until the results are completed. This will increase the query count in sql adapters until the adapters understand how to interpret and build these join queries (nosql adapters don't have joins so those will work).
Who needs N+1 select issues when we can have recursive queries baked right into the ORM! smh
Linkedin also uses Node.js and they found a 50% increase in development speeds as a result after making the switch a few years ago.
I am certainly more productive in Ruby or more recently Elixir than JavaScript on either the client or server.
@SignMeTheHELLUp is complaining about Waterline ORM, but I'd argue that Hibernate is worse (and it's an "industry standard"). It's just a fact of life that ANY ORM will suck because it tries to build an isomorphic API over several database abstractions.
Also, come on, entire world-class companies are based on a Node.js architecture (Uber comes to mind)[1]. If you can't write solid code in Node, you're probably just a shitty programmer.
[1] https://www.quora.com/What-is-the-technology-stack-behind-Ub...
Are you serious. Hibernate and all it's language-specific variants are actual feature-complete ORMs. Waterline falls flat as soon as you get past eager-fetching a child property. It's a toy.
I wasn't just complaining about Waterline either. Every time I had issues with Sails I had to dip into the Sails source and patch bugs out, eventually I replaced parts of Sails with libraries that actually worked. By the end of the project the only "Sails" left was the routing component...
Edit: Of the two sites you linked to, one is a splash page and the other is an aggregator that loads slowly. Neither are real-world LOB applications with complex logic underneath them.
I can write solid code on Node the same way I can on any PHP framework, but I'm experienced enough to know to look elsewhere when my requirements are complex.
Would love to hear more about this - if time permits, would be a great write-up.
> I wasn't just complaining about Waterline either. Every time I had issues with Sails I had to dip into the Sails source and patch bugs out, eventually I replaced parts of Sails with libraries that actually worked.
I don't even know what this means. Sails is basically just a router on top of express with grunt tying everything together. What part of sails did you have to "replace"? The i18n? Let's not be dramatic here.
But then again, your post about staying away from Node just showed how unhinged you are. I'm no language zealot, but that's just ignorant to say when world-class companies are using Node on incredible scales.
Moving fast and breaking things seems par for the course in javascript land, I don't really try to keep up.
I've ended up only using NodeJS for plumbing type apps (e.g. web hook listeners calling other APIs), definitely not for full on web apps, which I've found too-easily devolve into a mess of code.
Keeping up with anything in the NodeJS community is hard - from Node/NPM itself to all the OSS projects around it. I still use it, but I do definitely make fun of how often I'm destroying the node_modules directory and npm installing "fresh" due to the weirdest errors.
https://docs.npmjs.com/how-npm-works/npm3
At my current one, we are re-implementing a ton of very detailed business logic from a PHP/Cake app, while writing comprehensive functional and browser tests. We considered Sails.js but decided the framework was immature vs. Ruby on Rails.
Rails has worked great for us, and has a ludicrously evolved ecosystem, with fantastic gems available, Stack Overflow answers, and lots of other users filing and resolving Github bugs before us (most of the time).
Rails is not as trendy as Isomorphic Javascript, but Ruby is a pleasure to develop on.
The turbulence with Sails.js makes me feel even better about our choice.
The Trails project is developing thanks to Travis Webb and team, and his reasons are described in the pull request.
The Trails README includes this intro:
"Trails is built and maintained by former members of the Sails.js core team, and offers an upgrade path from existing Sails applications, but it utilizes exactly zero lines of code from the original Sails project."
I've looked over these issues and noticed Travis is just copy/pasting the same message stating "Sails.js is no longer actively maintained". It seems like this guy has a real vendetta against Mike (the creator of Sails) and is dead set on getting all current developers of Sails libraries to either make their library trails compatible or die. This guy really doesn't like Mike and even though he has some good points on making a new framework it seems there might also be some personal issues driving this decision.
Our company lives off consulting around the open-source tools we build and support. That's it.
If I were to speculate, I believe this diction has less to do with Travis hating Mike and more to do with the fear of being outmoded, i.e. "We built our library on SailsJS and it would be unthinkable/very difficult to change if SailsJS was subsumed by another project"
Comments on your main library give credence to this fear, such as the one posted by the main dev just recently in the Github issues:
> Waterlock has been struggling recently because of a lack of time from the guys that maintain it. I've tried to do what I can and so have the other guys. But there hasn't been enough going on recently.
Factoring in that Waterlock has 43 open issues since 2014 that have either not been closed or given a label, I can see why there would be uncertainty over this library's future.
For beginners, you can still use sails to build apps and also take the project structure of sails as a good starting point for building node.js applications.
The only minor gripe I had with sails is that the "neglected" vibe it gives on github.
Otherwise, I will continue to use sails and also check out trailsjs on the side.