5 ms·

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

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...
  - jondubois 11y ago
    The reason why Node.js cuts down on development times is due to the fact that you can have the same engineers working on both the frontend and backend - Basically it puts you in a situation where you can have a single engineer own a feature's development end-to-end. When you have a company which is split up between frontend and backend teams, this requires your engineers to coordinate their work with one another and this reduces overall productivity (you usually need a lot of back-and-forth to bring the feature to completion).
    - kyllo 11y ago
      Or you know, you could just hire developers who know more than one programming language.
      - jondubois 11y ago
        Yeah, but that narrows down your pool of developers a lot. There are a lot more JavaScript developers than there are JavaScript developers who also happen know RoR. I mean, sure, someone could learn RoR on the job, but in practice, will they actually do it? In all companies I worked for where the frontend and backend languages were different, developers tended to stick to one side of the fence. Developers just don't like context switching.
        SignMeTheHELLUp 11y ago
        In my experience any developer worth hiring can do complex frontend work (even by 2015/2016 standards) and backend work. I've never seen a "frontend only" or "backend only" developer.
        kyllo 11y ago
        Did I say that Ruby on Rails was the only option? On the other hand, if a developer cannot figure out Ruby on Rails (or Sinatra, or Django, or Flask, or any of the PHP frameworks), and does not even know SQL, do they really have any business doing server-side web development? Knowing JavaScript and one server-side web app framework/language is a pretty minimal requirement for a full-stack web developer. It boggles my mind to think that there are people working as professional developers that literally only know JavaScript. Those people should not be doing server-side development.
- lopatin 11y 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 ecosystem. You end up spending way more time on the Github issues page of your framework than you would for the frameworks of other languages (Python, Go, ...) where, for the most part, the tools just work.
  - pfooti 11y ago
    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.

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...
- jondubois 11y ago
  The reason why Node.js cuts down on development times is due to the fact that you can have the same engineers working on both the frontend and backend - Basically it puts you in a situation where you can have a single engineer own a feature's development end-to-end. When you have a company which is split up between frontend and backend teams, this requires your engineers to coordinate their work with one another and this reduces overall productivity (you usually need a lot of back-and-forth to bring the feature to completion).
  - kyllo 11y ago
    Or you know, you could just hire developers who know more than one programming language.
    - jondubois 11y ago
      Yeah, but that narrows down your pool of developers a lot. There are a lot more JavaScript developers than there are JavaScript developers who also happen know RoR. I mean, sure, someone could learn RoR on the job, but in practice, will they actually do it? In all companies I worked for where the frontend and backend languages were different, developers tended to stick to one side of the fence. Developers just don't like context switching.
      - SignMeTheHELLUp 11y ago
        In my experience any developer worth hiring can do complex frontend work (even by 2015/2016 standards) and backend work. I've never seen a "frontend only" or "backend only" developer.
      - kyllo 11y ago
        Did I say that Ruby on Rails was the only option? On the other hand, if a developer cannot figure out Ruby on Rails (or Sinatra, or Django, or Flask, or any of the PHP frameworks), and does not even know SQL, do they really have any business doing server-side web development? Knowing JavaScript and one server-side web app framework/language is a pretty minimal requirement for a full-stack web developer. It boggles my mind to think that there are people working as professional developers that literally only know JavaScript. Those people should not be doing server-side development.
lopatin 11y 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 ecosystem. You end up spending way more time on the Github issues page of your framework than you would for the frameworks of other languages (Python, Go, ...) where, for the most part, the tools just work.
- pfooti 11y ago
  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.