Currently a week or two in on a new project using Sails. Any alternatives? Originally, I was going to use just Hapi + Sequalize. Thanks
Status of Sails.js
21–30 of 74 posts
Re: Status of Sails.js
#22Didn'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?
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.
Re: Status of Sails.js
#23Earlier quoted context omitted.
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 ecosyste…
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.
Re: Status of Sails.js
#24Currently a week or two in on a new project using Sails. Any alternatives? Originally, I was going to use just Hapi + Sequalize. Thanks
Hapi+Bookshelf :)
Re: Status of Sails.js
#25Earlier quoted context omitted.
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 ecosyste…
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-s…
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 :)
Re: Status of Sails.js
#26I 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 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…
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.
Re: Status of Sails.js
#27I'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-Ub...
Re: Status of Sails.js
#28I'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…
> 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.
Re: Status of Sails.js
#29Earlier quoted context omitted.
> 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…
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.
If you only knew how much work needs to be done on Sails.js, you'd understand how inadequate 10 commits per month is :)
Re: Status of Sails.js
#30Currently a week or two in on a new project using Sails. Any alternatives? Originally, I was going to use just Hapi + Sequalize. Thanks
FWIW, Trails.js is based on hapi, and we will be adding Sequelize support after 1.0-beta is released in February.