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.
Depends on the kind of projects. In the "heavy" web framework category ("we take care of lots of the busy work for you"), an established project like Django can expect 256 commits a month:
ExpressJS, on the other hand, only had 5 commits this past month, but one could argue that it's not as "heavy" as SailsJS and others are trying to be.
I agree commit count by itself is not a good pulse on a project's life, but, as this thread shows, there's a lot of issues left unresolved. Not mentioned yet one of the lead developers posted on Sails.js future right here:
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.
For a kind of boring CRUD application you've got two major framwork issues: server and ORM. Node has a pretty vibrant bunch of app server libraries to choose from, ranging from simple but broadly-used (express) to highly-optimized and well-supported (hapi) to pretty esoteric (koa). There are others as well, but those three frameworks all get the job done exposing routes, templating HTML, and dealing with middleware-style abstraction layers to hook in your business logic. Personally, I dig hapi.js.
The problem with the node.js ecosystem that I see is in the ORM world. There exist ORM frameworks (waterline, bookshelf, etc), but they're a bit less actively-supported, a bit more kludgy, and that area is (subjectively to me) more likely to be a pain point. When I have issues on the back end, I end up having to write some custom SQL to fix them (which is easy enough, but hardly elegant). I rarely have framework-level problems with the stuff hapi.js is in charge of. As an example, I typically use bookshelf as a starting point for ORM stuff, but rolled my own hasmany and migrations code because I was unsatisfied with what bookshelf provided. Not a big deal, but also not standardized. I guess that may be one reason people end up using mongo - mongoose is a pretty handy library. I prefer postgres, so I'm stuck with my hybrid of raw SQL extending more generic ORM models.
I previewed sails.js a while ago when I was jumping into node from RoR (mainly so I could live in the dangerous world of websockets), and it was the all-in-one, monolithic nature of the framework that I found off-putting. Sails at the time didn't support hmabtm relationships at all, and it was going to be pretty difficult to lever in the business logic I needed to support on the back end (view permissions on both sides of the join). I ended up enjoying the decoupled app / orm framework model, since it meant I had more mix-and-match flexibility.
Ultimately, there's definitely no one true batteries included framework to do the entirety of a CRUD application in node.js (although who knows, one may emerge), but I'm enjoying the fragmentation's flipside: mix-and-match stuff, and lots of little libraries that just do one thing.
There is a simple reason hapi, kraken etc. are built by large entities that have complex backends and are not really calling storage layer directly from node and even if they did they would not have used ORM. So they have 0 incentive to bake it in into the framework. At the other end of the spectrum are former "front-enders" lacking background to develop decent ORM :)
^^ after spending several man years of effort on the subject, that's the inevitable boundary in ORM development, IMHO. It was this that made me realize that we needed to be focused on providing a better, cleaner way to allow running custom queries using a declarative, database-agnostic syntax, rather than focusing on implementing even-deeper support for xD/A queries.
Also I don't mean to nitpick, but I'm hearing a lot of negativity towards Waterline from a couple of the commenters in this thread, and I'm not clear on how it lines up with specific, actionable criticism that I or the rest of the core team can do anything about. I get that having to use a framework or stack for work when you aren't excited about it is horrible (it was originally how I felt about Grails and Hibernate when I was using them every day in 2011).
But I think it's important to keep in mind that this is always "compared to what". The Java ecosystem has had years to develop tools for working with data, and it certainly still provides more mature utilities out of the box than you're going to get as someone new to the Node world, even today. But I firmly believe in the power and flexibility of JavaScript-- not because it's a good language or anything-- but because we all had to learn it to do front-end development in the browser. And so will the next generation of developers.
Whether we like it or not, Node.js is here to stay. And for me, that's a tremendously exciting thought. A future with the world sharing a common programming language is a goal worth fighting for. It's a future that dramatically lowers the barrier to entry to full stack web development, and vastly expands the pool of people willing and able to contribute to free and open-source technology.
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).
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.
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.
On the other hand, if a developer cannot figure out Ruby on Rails (or Sinatra, or Django, or Flask, or any of the PHP frameworks), and does not even know SQL, do they really have any business doing server-side web development?
Knowing JavaScript and one server-side web app framework/language is a pretty minimal requirement for a full-stack web developer. It boggles my mind to think that there are people working as professional developers that literally only know JavaScript. Those people should not be doing server-side development.
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.
There are mature, production-ready server-side web app frameworks with relational database adapters in literally every mainstream programming language (and many of the obscure ones too) except for JavaScript. I didn't say you have to do Ruby on Rails. If you prefer Python, then you can just use Django, it is more or less equivalent to Rails.
zensavona was using ruby and elixir in the client side though? What does he do to be more productive using those? Any thoughts?
Edit: Unless he is only using helpers? Then I wonder how much power he can do with client side applications compared with modern javascript/typescript tools...
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 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.
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.
"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
I'm not saying it's a bad thing man i understand the situation in fact i'm pretty excited to see what Trails has to offer, I was even hoping to make waterlock trails compatible or work on something for Trails. I'm just saying it's important to keep these things upfront, i commend you and your company for taking on this task and like you said before (somewhere i forget) it's refreshing to be transparent about the motivations and issues at hand.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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). (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.)
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.
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.
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?
He owned some of the assets, still, including the github org. Even though we negotiated an agreement, and were operating the company under the assumptions of that agreement, McNeil refused to sign it at the last minute and spent the past two months clawing everything back that he could. We still own the Balderdash LinkedIn page and npm account, for example.
He refuses to speak with me directly, so there's no resolution to this yet. Nor do we really understand why he decided on this course of action at all. I hope to bring things back to some equilibrium, but one permanent change is that we are no longer supporting Sails, and are directing all our efforts toward developing Trails.
The maintained-ness of Sails is really a separate issue from the ceo-schism drama. There are plenty of other literature which discuss the technical deficits of Sails, and the incredible amount of work it needs merely to be viable as an enterprise framework. That it relies on EOL'd dependencies, and has no plans to upgrade them, is an example.
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.
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 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.