Live data from Hacker News

Status of Sails.js

github.com

41–50 of 74 posts

Re: Status of Sails.js

#41

Earlier quoted context omitted.

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.

The reason why Node.js cuts down on development times is due to the fact that you can have the same engineers working on both the frontend and backend - Basically it puts you in a situation where you can have a single engineer own a feature's development end-to-end. When you have a company which is split up between frontend and backend teams, this requires your engineers to coordinate their work with one another and…

Or you know, you could just hire developers who know more than one programming language.

Re: Status of Sails.js

#42
I've been using sails for about 18 months, this has me pretty worried and I've experienced a lot of the issues (bugs, long delays on issues and pull requests) others have described. What other nodejs stacks (hapi + ORM?, kraken + ??, etc) do others use to create server apis without having to write a ton of boilerplate for each route / model?

Re: Status of Sails.js

#43

I've been using sails for about 18 months, this has me pretty worried and I've experienced a lot of the issues (bugs, long delays on issues and pull requests) others have described. What other nodejs stacks (hapi + ORM?, kraken + ??, etc) do others use to create server apis without having to write a ton of boilerplate for each route / model?

Interestingly, even though the node.js community is growing quickly and has a lot of great tools, I think your options are mainly Sails.js and Meteor.

Meteor, imho, focuses much more efforts around building shiny things to convincing new developers to try it out. It has gained a reputation of being a great framework for writing hello world in 60 seconds, but not for building real business applications. Sails is a great tool, but unfortunately is dying, as evidenced by the attitude of the creators (who have moved on to work on other things), and the multiple articles on hackernews and elsewhere discussing whether it is dying. That answer, obviously, is yes.

It is for these reasons that we (several of the core Sails.js maintainers) decided to invest in building a new framework, where we could offer a Sails-like development experience using modern node.js tools and design practices. If anyone is interested in working with us, we'd be happy to talk with you: https://github.com/trailsjs/trails.

Re: Status of Sails.js

#44
post #21

Currently a week or two in on a new project using Sails. Any alternatives? Originally, I was going to use just Hapi + Sequalize. Thanks

We ported from Sails to Hapi and Sequelize several months ago. The issues with Sails have been covered exhaustively. (Finding a third SQL injection vulnerability in the default behaviour of Sails+Wuterline, as we lovingly nicknamed it, was the final straw for us.) We have zero regrets.

Re: Status of Sails.js

#45

I've been using sails for about 18 months, this has me pretty worried and I've experienced a lot of the issues (bugs, long delays on issues and pull requests) others have described. What other nodejs stacks (hapi + ORM?, kraken + ??, etc) do others use to create server apis without having to write a ton of boilerplate for each route / model?

Interestingly, even though the node.js community is growing quickly and has a lot of great tools, I think your options are mainly Sails.js and Meteor. Meteor, imho, focuses much more efforts around building shiny things to convincing new developers to try it out. It has gained a reputation of being a great framework for writing hello world in 60 seconds, but not for building real business applications. Sails is a gre…

Thanks, I know alpha release for trails is in the next few days, when do you expect to have a production release? I know trails is supposed to have a pack that allows you to use it with current sails codebases, how well baked do you expect that to be? Will anything in the sails codebase that goes beyond the simple controllers, models, services, config need to be refactored? For example: custom blueprints, sails hooks, code based on model definitions pulled from sails config, etc.

Re: Status of Sails.js

#46
post #8

Earlier quoted context omitted.

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 get…

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.

"We don't distract ourselves with VC-funded side projects". Ouch. These 'low blows' are childish at best. IMO, I wouldn't think a YC backed + VC funded company would be a side project.

It's good that you can be passionate about what you are doing, but it's obvious there are other motivators

EDIT: sp and example motivator -> https://twitter.com/TravisWebbUSA/status/679406525358600192

Re: Status of Sails.js

#47
post #41

Earlier quoted context omitted.

The reason why Node.js cuts down on development times is due to the fact that you can have the same engineers working on both the frontend and backend - Basically it puts you in a situation where you can have a single engineer own a feature's development end-to-end. When you have a company which is split up between frontend and backend teams, this requires your engineers to coordinate their work with one another and…

Or you know, you could just hire developers who know more than one programming language.

Yeah, but that narrows down your pool of developers a lot. There are a lot more JavaScript developers than there are JavaScript developers who also happen know RoR.

I mean, sure, someone could learn RoR on the job, but in practice, will they actually do it? In all companies I worked for where the frontend and backend languages were different, developers tended to stick to one side of the fence. Developers just don't like context switching.

Re: Status of Sails.js

#48
post #41

Earlier quoted context omitted.

The reason why Node.js cuts down on development times is due to the fact that you can have the same engineers working on both the frontend and backend - Basically it puts you in a situation where you can have a single engineer own a feature's development end-to-end. When you have a company which is split up between frontend and backend teams, this requires your engineers to coordinate their work with one another and…

Or you know, you could just hire developers who know more than one programming language.

It take longer to adopt and learn RoR than ES6. Both have their owns strength but Javascript and Python skills can be apply to any organizations, RoR is quite limited.

Re: Status of Sails.js

#49
post #41

Earlier quoted context omitted.

Or you know, you could just hire developers who know more than one programming language.

Yeah, but that narrows down your pool of developers a lot. There are a lot more JavaScript developers than there are JavaScript developers who also happen know RoR. I mean, sure, someone could learn RoR on the job, but in practice, will they actually do it? In all companies I worked for where the frontend and backend languages were different, developers tended to stick to one side of the fence. Developers just don't…

In my experience any developer worth hiring can do complex frontend work (even by 2015/2016 standards) and backend work. I've never seen a "frontend only" or "backend only" developer.

Re: Status of Sails.js

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

Post reply on HN