5 ms·

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 framewor

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.

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.