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