
Status of Sails.js - kevinob11
https://github.com/balderdashy/sails/issues/3429
======
jakejake
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.

~~~
kevinburke
> 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/](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](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...](https://kev.inburke.com/kevin/safely-moving-a-large-
shrinkwrapped-dependency/)

~~~
jakejake
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.

~~~
traviswebb
If you only knew how much work needs to be done on Sails.js, you'd understand
how inadequate 10 commits per month is :)

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

[https://github.com/balderdashy/sails/issues/3429](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.

------
SignMeTheHELLUp
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

~~~
jondubois
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.

~~~
zensavona
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.

~~~
jondubois
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
this reduces overall productivity (you usually need a lot of back-and-forth to
bring the feature to completion).

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

~~~
jondubois
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.

~~~
SignMeTheHELLUp
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.

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

[1] [https://www.quora.com/What-is-the-technology-stack-behind-
Ub...](https://www.quora.com/What-is-the-technology-stack-behind-Uber)

~~~
SignMeTheHELLUp
> 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.

~~~
rargulati
> 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.

~~~
dvt
I have a feeling it's just nonsense. There's not much to re-write to begin
with. Sails.js is a thin-ish layer on top of express that uses grunt to tie
everything together. Waterline is the biggest component, but it's not even
technically part of Sails.js proper.

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

~~~
paulddraper
You're going to love npm3 then. It installs different versions depending on
the order you install them.

[https://docs.npmjs.com/how-npm-works/npm3](https://docs.npmjs.com/how-npm-
works/npm3)

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

~~~
qaq
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.

------
jph
Compare the new Trails JS:
[https://github.com/trailsjs/trails](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."

~~~
duhruh
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...](https://github.com/waterlock/waterlock/issues/99#issuecomment-166167161)

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.

~~~
traviswebb
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.

~~~
dandanisaur
"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](https://twitter.com/TravisWebbUSA/status/679406525358600192)

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

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

~~~
uptownJimmy
It befuddles me as to why the folks at Meteor chose MongoDB. I know Mongo's
marketing was superb, but the product itself is/was so shoddy.

Never mind the fact that you gotta have SQL for almost any robust enterprise
app, which, in turn, is such a huge chunk of the market.

I just don't understand the hitching of the Meteor wagon to that broke-down
MongoDB horse.

------
kevinob11
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?

~~~
traviswebb
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](https://github.com/trailsjs/trails).

~~~
kevinob11
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.

------
orthoganol
Didn't the core people behind Sails essentially abandon it for the YCombinator
startup Treeline.io?

Also, hasn't Treeline been in 'preview mode' for almost a year now?

~~~
joeblau
I remember when I first saw the Treeline demo, I was blown away. It seemed
like a great framework for striking web services together to solve problems
and build great products. Over the past year, I've become weary of any
frameworks that sit on top of Node. I currently run gitignore.io and I've had
problems using Kraken.js due to lack of updates to the framework or
incompatible dependency maintenance. If I were to go back, I would probably
just use straight Express and cut out all of the frameworks. They just seem to
generate just enough buzz to be functionally interesting and then they fall
apart which is a terrible foundation to base any project on.

~~~
sisk
Hey Joe. Would love to better understand the problems you've been having. Mind
firing off an issue to discuss?

~~~
joeblau
Problems with Kraken.js? I don't use Treeline.

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

~~~
sergiotapia
Meteor - it's webdev that doesn't suck.

~~~
uptownJimmy
It's webdev that doesn't support a properly robust db. When they finally fix
that Achilles' heel, they might have a chance of lasting long-term. MongoDB is
not gonna cut it.

------
k__
Are frameworks like this really a thing anymore? Okay, I have to admit I
always avoided frameworks that incorporate code generators, so I don't really
know.

When using Node.js I always just throw some small modules together and be done
with it. It also seems to me, that newer modules encourage this behavior, for
example Koa is more modular than Express.

------
uniacid
Isn't Travis the CEO of balderdash.io?

I don't get it... CEO and Founder don't seem to happy with eachother...

~~~
traviswebb
We've started a new company to support the development of Trails. I don't want
to go into the gossip of why things fell apart with McNeil and Treeline, but
suffice it to say that we are no longer involved in the development or
maintenance of Sails.

Trails will be the replacement for Sails. Modern, maintained, open, and
community-run.

------
fapjacks
"Locked to contributors" is the new tyranny.

~~~
traviswebb
See also:
[https://twitter.com/TravisWebbUSA/status/679406525358600192](https://twitter.com/TravisWebbUSA/status/679406525358600192)

------
dbg31415
Little more digging... here's what I think is going on, and it's sad.

I've pieced this together based on Google searches.

Sails was started by Mike McNeil, who also started a company called Balderdash
to do consulting and dev work using Sails. From what I can tell Balderdash
isn't quite a "real" company in that everyone listed as working there also
does other things at present
([http://i.imgur.com/dFVQawi.png](http://i.imgur.com/dFVQawi.png)). (Mike also
started a product company that utilizes Sails called Treeline. Full
disclosure, I've been to some of their meetups in Austin, they seemed like
clever guys.)

LinkedIn paints a slightly different picture
([https://www.linkedin.com/vsearch/p?f_CC=2604050](https://www.linkedin.com/vsearch/p?f_CC=2604050))
with a few more employees listed, including listing both Mike and Travis Webb
as "CEO" ([http://i.imgur.com/onnhqqO.png](http://i.imgur.com/onnhqqO.png)).

Given the size of the company, and the fact that the staff seem to be doing
other things, I'd assume someone told Travis, "Hey you can be CEO, but you
have to hit some metrics... and if you don't you can't be CEO any more..." And
given some of the bickery on the other threads... maybe it wasn't clear or
maybe those metrics weren't possible given the range of projects Mike and the
other people were working on. We've all been there... Client says, "Yeah we'd
like to work with you, but... Do A, B, C, and fix X, Y, Z first..." maybe
Travis needed Mike's help and didn't get it. But who knows, and regardless it
sounds like Travis was shown the door.

So, and you can see this in the numerous videos where Travis has been
promoting Sails the last few years (just Google, he comes up for all the
training / discussions around Sails), Travis really liked Sails, and had his
feelings hurt because he couldn't work on the project he really liked. And in
response, he's now saying, "Burn the ships, Sails is dead, everyone come with
me to Trails."

Guy goes from being a huge Sails fanboy in hours and hours of videos that are
posted online, to coming here 2 weeks later saying, paraphrased, "I'm going to
build my own Sails... with blackjack, and hookers." This scenario sucks for
everyone.

You hire a good dev, someone who knows how to get the technology side done...
he offers to step up to a bigger role... but who knows, maybe he can't make
sales, can't retain customers, he isn't a leader, or isn't focused on the
company needs because he's only interested in being a dev... but wants the
title of CE-something because he's 22 and it's an ego boost... so rather than
leave with dignity, and move on to his next job going back to what he was good
at, he is out to sink the people he had been working with.

That's my read. I could be totally wrong, but the drama here peeked my
curiosity and after an hour of digging around that's what I came up with.

~~~
traviswebb
Your assessment is perfectly logical based on the information you have
available, and also mostly wrong.

First, I'm not 22, and our COO ran the largest jQuery cobsulting firm
(appendTo) for 5 years. Second, McNeil did not hire us, we purchased the
company; McNeil has no ownership in the "new" Balderdash. Your educated
guesses about hitting metrics and so forth don't apply to anything here.

Mike McNeil needs control of Sails.js because he promised it to his VC
investors behind treeline. We did not know this when we entered into the
acquisition of Balderdash, and that's not what we signed up for. Since we were
lied to for nearly a year, we are pivoting the company and our open-source
efforts toward other things. Trails is one of those things.

~~~
dbg31415
Not sure how Mike can kick you out if he doesn't own the company. Sounds like
either he does own the company, or he's not the one who kicked you out...
Anyway I'm inclined to believe the company website. If you bought the company
you've got access to the site? DNS? Or a contract? Doesn't seem like that's
the case given your actions trying to get people to move away from Sails.

So yeah, you saying the project is dead when you know others are still working
on it, and trying to tell other people to switch with you -- seems at best
shady. Getting a project rolling is hard enough without an active saboteur.
Not a great way to get your own business going. Seems to me -- outsider
perspective -- you should just move on and focus on your own thing. Clean
breaks, right?

~~~
uniacid
Having witnessed feuds between Founder and CEO before they're never a pretty
sight, so thats why the future of Sails.js has been very disconcerting.

Hopefully relationships can be amended amicably and if Sails.js is truly dead
in the water then hopefully Trails.js will pick up where it left off and on
better footing I hope, but it will take some time and also some proper PR
might of been helpful to the many Sails.js users as well as it didn't need to
reach this point, also on that PR note should we expect that they can easily
port over their Sails.js projects over to Trails.js?

I was hoping to re-visit Sails.js for a project but considering all that's
been happening I'm not sure I should just go with something else like
Python+Flask and let Trails.js mature a bit more.

~~~
mikermcneil
I'm sorry that this debacle has negatively impacted your opinion of the
framework. Other open-source maintainers had warned me in the past that this
kind of thing is par for the course as any project grows, but it doesn't make
it any easier to deal with when it happens to you. In the mean time, it has
certainly made my family's holidays unpleasant, and disrupted the lives of the
rest of our team.

I posted a few important clarifications here in the original issue:
[https://github.com/balderdashy/sails/issues/3429#issuecommen...](https://github.com/balderdashy/sails/issues/3429#issuecomment-168801414)

