9 ms·

Status of Sails.js

93 points by kevinob11 11y ago

fideloper 11y ago
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 11y ago
  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
SignMeTheHELLUp 11y ago
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 11y ago
  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 11y 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.
    - maxpupmax 11y ago
      RoR, apparently. http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html http://highscalability.com/blog/2012/10/4/linkedin-moved-fro...
    - kevindeasis 11y ago
      More productive in the client-tier without using Javascript? I'd like to know how that works.
      - sotojuan 11y ago
        ClojureScript, Elm, etc.
        kevindeasis 11y ago
        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...
    - 11y ago
jph 11y ago
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 11y ago
  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#issuecomment-166167161 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.
  - paulddraper 11y ago
    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.
  - traviswebb 11y ago
    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.
    - 11y ago
jondubois 11y ago
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 11y ago
  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.
jakejake 11y ago
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 11y ago
  > 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-shrinkwrapped-dependency/ https://kev.inburke.com/kevin/safely-moving-a-large-shrinkwr...
  - 11y ago
orthoganol 11y ago
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 11y ago
  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 11y ago
    Hey Joe. Would love to better understand the problems you've been having. Mind firing off an issue to discuss?
    - joeblau 11y ago
      Problems with Kraken.js? I don't use Treeline.
dbg31415 11y ago
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.
uniacid 11y ago
Isn't Travis the CEO of balderdash.io? I don't get it... CEO and Founder don't seem to happy with eachother...
- traviswebb 11y ago
  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.
delbel 11y ago
Currently a week or two in on a new project using Sails. Any alternatives? Originally, I was going to use just Hapi + Sequalize. Thanks
- qaq 11y ago
  Hapi+Bookshelf :)
- traviswebb 11y ago
  FWIW, Trails.js is based on hapi, and we will be adding Sequelize support after 1.0-beta is released in February.
- sergiotapia 11y ago
  Meteor - it's webdev that doesn't suck.
  - uptownJimmy 11y ago
    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.
- connor4312 11y ago
  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.
dvt 11y ago
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-Uber https://www.quora.com/What-is-the-technology-stack-behind-Ub...
- SignMeTheHELLUp 11y ago
  > 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 11y ago
    > 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.
    - 11y ago
dankohn1 11y ago
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 11y ago
  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.
kevinob11 11y ago
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 11y ago
  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 11y ago
    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.
  - gmmeyer 11y ago
    Keystone, too: https://github.com/keystonejs/keystone https://github.com/keystonejs/keystone
p0larboy 11y ago
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.
k__ 11y ago
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.
dbg31415 11y ago
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.
fapjacks 11y ago
"Locked to contributors" is the new tyranny.
- traviswebb 11y ago
  See also: https://twitter.com/TravisWebbUSA/status/679406525358600192 https://twitter.com/TravisWebbUSA/status/679406525358600192

93 points by kevinob11 11y ago

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 11y ago
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

SignMeTheHELLUp 11y ago

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 11y ago
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 11y 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.
  - maxpupmax 11y ago
    RoR, apparently. http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html http://highscalability.com/blog/2012/10/4/linkedin-moved-fro...
  - kevindeasis 11y ago
    More productive in the client-tier without using Javascript? I'd like to know how that works.
    - sotojuan 11y ago
      ClojureScript, Elm, etc.
      - kevindeasis 11y ago
        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...
  - 11y ago

jph 11y ago

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 11y ago
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#issuecomment-166167161 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.
- paulddraper 11y ago
  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.
- traviswebb 11y ago
  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.
  - 11y ago

jondubois 11y ago

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 11y ago
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.

jakejake 11y ago

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 11y ago
> 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-shrinkwrapped-dependency/ https://kev.inburke.com/kevin/safely-moving-a-large-shrinkwr...
- 11y ago

orthoganol 11y ago

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 11y ago
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 11y ago
  Hey Joe. Would love to better understand the problems you've been having. Mind firing off an issue to discuss?
  - joeblau 11y ago
    Problems with Kraken.js? I don't use Treeline.

dbg31415 11y ago

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.

uniacid 11y ago

Isn't Travis the CEO of balderdash.io? I don't get it... CEO and Founder don't seem to happy with eachother...

traviswebb 11y ago
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.

delbel 11y ago

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

qaq 11y ago
Hapi+Bookshelf :)
traviswebb 11y ago
FWIW, Trails.js is based on hapi, and we will be adding Sequelize support after 1.0-beta is released in February.
sergiotapia 11y ago
Meteor - it's webdev that doesn't suck.
- uptownJimmy 11y ago
  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.
connor4312 11y ago
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.

dvt 11y ago

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-Uber https://www.quora.com/What-is-the-technology-stack-behind-Ub...

SignMeTheHELLUp 11y ago
> 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 11y ago
  > 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.
  - 11y ago

dankohn1 11y ago

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 11y ago
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.

kevinob11 11y ago

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 11y ago
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 11y ago
  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.
- gmmeyer 11y ago
  Keystone, too: https://github.com/keystonejs/keystone https://github.com/keystonejs/keystone

p0larboy 11y ago

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.

k__ 11y ago

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.

dbg31415 11y ago

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.

fapjacks 11y ago

"Locked to contributors" is the new tyranny.

traviswebb 11y ago
See also: https://twitter.com/TravisWebbUSA/status/679406525358600192 https://twitter.com/TravisWebbUSA/status/679406525358600192