Live data from Hacker News

Status of Sails.js

github.com

1–10 of 74 posts

Re: Status of Sails.js

#2
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.

Re: Status of Sails.js

#3
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

Re: Status of Sails.js

#4
Compare the new Trails JS: https://github.com/trailsjs/trails

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."

Re: Status of Sails.js

#5
That's what happens when the maintainers of a project start to put their hands in too many baskets. They are undertaking big and highly speculative projects instead of projects which address immediate community pain points.

I think Meteor did a better job in this respect. That said, Meteor's services are a bit too expensive.

Re: Status of Sails.js

#6
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.

Re: Status of Sails.js

#7

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…

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.

Re: Status of Sails.js

#8
post #4

Compare the new Trails JS: https://github.com/trailsjs/trails 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 Sail…

Yea I've noticed this too, mostly because Travis threw up a comment on multiple GH issues on my Sails library e.g. https://github.com/waterlock/waterlock/issues/99#issuecommen...

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.

Re: Status of Sails.js

#9

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…

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.

50% increase in development speed after making the switch from what?

I am certainly more productive in Ruby or more recently Elixir than JavaScript on either the client or server.

Post reply on HN