4 ms·

Wait, Shyp uses Sails.js for their framework? Huh, they might be the most well-known startup to use it. Sails development has really slowed down lately, especia

Wait, Shyp uses Sails.js for their framework? Huh, they might be the most well-known startup to use it. Sails development has really slowed down lately, especially since one of their core creators/commiters got into YC with a different project; I wonder how Shyp feels about that... "Avoiding Sails isn’t possible in every situation, but we’ve found it’s a useful design principle - it helps us separate our business logic and our data storage layer, and will make it easier for us to move off Sails in the future." Ooops.

angersock 11y ago
Well, to be fair, one of the patterns I've seen with Rails projects is to move as much out of Rails proper as possible, and treat it just as your web/(maybe)database interface.
kevinburke 11y ago
Yep - we've run into a lot of really unexpected behavior with it and with the ORM (Waterline), so we try to restrict ourselves to "the minimum possible framework subset that gets the code to run". For example, we disable `dynamicFinders`, don't use policies, don't use blueprints, don't use Waterline's associate/populate/destroy, don't use the "turn any controller function into a named route" setting, don't use globals, disabled all of the Grunt/websockets junk, and overwrote all of the error response handlers. The result is that day to day we're writing something that resembles an Express app with its own `routes` file. We're looking to move off of Waterline/Sails entirely, it's slow going though since we're a small team and it's tough to prioritize that, as it "works" now. Every company has parts of their tech stack that don't do a great job - we're somewhat fortunate this one is easy to mitigate.
- iLoch 11y ago
  Sounds like you guys pulled out everything except for Express. I too found the more I used Sails the less useful it became, as though it was missing a solution for anything lying outside of the very basics. Compare Sails to say, Laravel, and you begin to see how much work needs to be put in to bring it up to date.
  - merb 11y ago
    That happens with every Framework. That's why we migrated from Django to Playframework. Django is great, except for the thing we do / the expertise I / we have. Play framework is way more "raw" than the most of the framework's I've seen. Also I use Slick but only the SQL part of it and the Codegen. It's so great to write RAW Sql while persisting objects easily and type safe without a big layer in between.
    - lmm 11y ago
      To my mind, and as a spray user, play is still huge and does too much.
      - merb 11y ago
        You are correct Playframework still does too much for the most people, however we are using a lot of things from the framework, basically json, forms, templates, the new DI layer, the ws library (which still is not usable on spray :(:() and the plugin layer. Mostly I think we could easily switch to Spray, however currently I really liked Play in his current version.
mikermcneil 11y ago
Never fear, our new project compiles Sails.js apps-- the core of what we're trying to solve is exactly that (the transition between using a more heavy-handed framework, and being able to customize/optimize/understand minutia as needed). More on the tech here: https://www.youtube.com/watch?v=nZKG7hLhbRs https://www.youtube.com/watch?v=nZKG7hLhbRs
- mikermcneil 11y ago
  Also, in case it's helpful, figured I'd mention that we just finished rearchitecting sailsjs.org and the doc compilation process to improve the permanence of links and make the experience of searching for stuff from the docs on Google better (latest updates here: https://github.com/balderdashy/www.sailsjs.org/commits/master https://github.com/balderdashy/www.sailsjs.org/commits/maste...) Kevin, I know that was something you (rightfully) have a lot of energy about.
tjwebbusa 11y ago
Being able to move "off" of Sails, interestingly, is a design principle of Sails itself. Sails is built on common node.js modules (express, socket.io, etc) and uses standard express middleware/APIs so that pieces of a Sails app can be ineroperable with other frameworks and tools. Waterline (the ORM layer) is designed to work with any database so that you aren't locked to a single vendor. It'd be hypocritical if we wanted to liberate you from other tools, but try to lock you into using Sails, wouldn't it? We feel that that's a feature, not a bug. There are much larger companies (Fortune 100) that use Sails.js. This isn't a knock against Shyp at all, and I'm glad they're using Sails, I'd just like to clear up whatever the source of your misconception is. Sails, Waterline, and the many related modules are all in active development. (Disclaimer: I work for Balderdash, the company that created Sails)

angersock 11y ago

Well, to be fair, one of the patterns I've seen with Rails projects is to move as much out of Rails proper as possible, and treat it just as your web/(maybe)database interface.

kevinburke 11y ago

Yep - we've run into a lot of really unexpected behavior with it and with the ORM (Waterline), so we try to restrict ourselves to "the minimum possible framework subset that gets the code to run". For example, we disable `dynamicFinders`, don't use policies, don't use blueprints, don't use Waterline's associate/populate/destroy, don't use the "turn any controller function into a named route" setting, don't use globals, disabled all of the Grunt/websockets junk, and overwrote all of the error response handlers. The result is that day to day we're writing something that resembles an Express app with its own `routes` file. We're looking to move off of Waterline/Sails entirely, it's slow going though since we're a small team and it's tough to prioritize that, as it "works" now. Every company has parts of their tech stack that don't do a great job - we're somewhat fortunate this one is easy to mitigate.

iLoch 11y ago
Sounds like you guys pulled out everything except for Express. I too found the more I used Sails the less useful it became, as though it was missing a solution for anything lying outside of the very basics. Compare Sails to say, Laravel, and you begin to see how much work needs to be put in to bring it up to date.
- merb 11y ago
  That happens with every Framework. That's why we migrated from Django to Playframework. Django is great, except for the thing we do / the expertise I / we have. Play framework is way more "raw" than the most of the framework's I've seen. Also I use Slick but only the SQL part of it and the Codegen. It's so great to write RAW Sql while persisting objects easily and type safe without a big layer in between.
  - lmm 11y ago
    To my mind, and as a spray user, play is still huge and does too much.
    - merb 11y ago
      You are correct Playframework still does too much for the most people, however we are using a lot of things from the framework, basically json, forms, templates, the new DI layer, the ws library (which still is not usable on spray :(:() and the plugin layer. Mostly I think we could easily switch to Spray, however currently I really liked Play in his current version.

mikermcneil 11y ago

Never fear, our new project compiles Sails.js apps-- the core of what we're trying to solve is exactly that (the transition between using a more heavy-handed framework, and being able to customize/optimize/understand minutia as needed). More on the tech here: https://www.youtube.com/watch?v=nZKG7hLhbRs https://www.youtube.com/watch?v=nZKG7hLhbRs

mikermcneil 11y ago
Also, in case it's helpful, figured I'd mention that we just finished rearchitecting sailsjs.org and the doc compilation process to improve the permanence of links and make the experience of searching for stuff from the docs on Google better (latest updates here: https://github.com/balderdashy/www.sailsjs.org/commits/master https://github.com/balderdashy/www.sailsjs.org/commits/maste...) Kevin, I know that was something you (rightfully) have a lot of energy about.

tjwebbusa 11y ago

Being able to move "off" of Sails, interestingly, is a design principle of Sails itself. Sails is built on common node.js modules (express, socket.io, etc) and uses standard express middleware/APIs so that pieces of a Sails app can be ineroperable with other frameworks and tools. Waterline (the ORM layer) is designed to work with any database so that you aren't locked to a single vendor. It'd be hypocritical if we wanted to liberate you from other tools, but try to lock you into using Sails, wouldn't it? We feel that that's a feature, not a bug. There are much larger companies (Fortune 100) that use Sails.js. This isn't a knock against Shyp at all, and I'm glad they're using Sails, I'd just like to clear up whatever the source of your misconception is. Sails, Waterline, and the many related modules are all in active development. (Disclaimer: I work for Balderdash, the company that created Sails)