5 ms·

When you say languages, do you really mean frameworks? It seems like languages are fairly general purpose and don't go out of their way to tell you how to build

by dcwca 11y ago

When you say languages, do you really mean frameworks? It seems like languages are fairly general purpose and don't go out of their way to tell you how to build your application. Node is more in the "language" camp than the "framework" camp, and there are bunch of frameworks on top of it that give you the structure you're looking for.

blowski 11y ago
Anything. I'm a pragmatic developer who just wants solutions that help me pay the bills. It's precisely for that reason that Node has been a problem for me - it's caused much more than its fair share of headaches, when compared to Ruby, Python, PHP, Bash, Go. Perhaps using a framework would make things easier, but I'm reticent to rely on it in the main part of the project when it causes so many problems just in the small parts.
- nilliams 11y ago
  Can you give an actual example of the 'so many problems' you describe? Your previous comments address the paradox-of-choice idea, but the uncontroversial path in Node is to 'just use Express' right? How it that a worse situation than in other languages where there are also trendy frameworks competing against the default option. You name PHP as a better situation but from what I gather PHP is even worse at casting off legacy frameworks. Laravel is the new trendy, whereas it was CodeIgniter/Symphony before that and EE/Wordpress before that. And in Ruby, there's similar competition over an alternative to Rails [0]. [0] https://blog.engineyard.com/2015/life-beyond-rails-brief-look-alternate-web-frameworks-ruby https://blog.engineyard.com/2015/life-beyond-rails-brief-loo...
  - blowski 11y ago
    Sure. There was the decision a couple of years back to stop using self signed certificates. I spent a couple of hours wondering why a server I was running that compiled SASS on deployment suddenly stopped working, and it turned out to have been this. A more recent example comes from Zombie, which I use for functional testing. When they moved to v3, they required io.js instead of Node. So eventually I decided to go with Zombie 3 and moved to io.js, but then another library broke which required Node instead of io.js. They're the two big ones that stand out, but there have been lots of other small annoyances.
    - brazzledazzle 11y ago
      I don't have a dog in this fight but the certificate thing sounds a lot like they corrected a significant security issue rather than API instability.
      - blowski 11y ago
        True enough, but they didn't tell anyone they'd done it for hours after they pushed out the changes. A notice on the terminal after the update should have been possible, or at least a big message on the homepage. But nothing - only an angry GitHub issues queue with random suggested causes and fixes.
- notNow 11y ago
  Software development is not about chasing the latest shiny fad or trend on the market, it's about solving real-world problems by researching available solutions. So, if you think that Node doesn't fit or not equipped enough to solve your problems, you're welcome to check other solutions till you find the one most suitable to the problem at hand. So, if you think that Ruby or Python could get things done for you and you're very familiar with them, go for either and get it done but to pick on Node just because you don't quite grasp its inner workings is really odd of you and the whole reasoning behind your critique is rather absurd.
  - blowski 11y ago
    It's not absurd to say "I'd like to use Node because of its performance and because it's easier to hire for, but only if it were more stable and had better documentation". As somebody who has to consider trade-offs between short-term and long-term costs for clients, these are very real problems for me.
    - Touche 11y ago
      Node's documentation really is terrible. The fact that it doesn't show what arguments functions take, what types are expected, etc. is pretty sad in 2015. The documentation is barely better than your typical side-project readme.md file, at best you get 1 example of an api's usage (always the most basic use-case only, of course).
  - drumdance 11y ago
    Preach. I inherited a Node project for which Rails was a much better solution for our use case. It's been fun learning a new platform, but for our needs Rails would have been fine. The only conceivable reason I can see they chose Node is because it's cool.
- mikekchar 11y ago
  In our shop we actually use all of Ruby, Node, Go, Python and Bash (in about that order of code volume). Honestly, for instability of 3rd party libraries Node is pretty bad, but Ruby is not really far behind. I am sure that I have spent more time debugging other people's code in Ruby than in Javascript. Having said that the IO split has been a royal PITA. We got pegged to Node 10.x because JSDom only supports IO and Jest (which is what we wanted JSDom for) only supports Node :-P. I've been waiting a year for it to get cleared up. It sounds like we made the right choice, though, because in this thread the people who are complaining about Node seem to be the ones who tried switching back and forth between IO and Node. There is actually only one bug in Node that has impacted me (related to the way connections are shut down) and it isn't fixed yet in master so not upgrading hasn't really impacted us. We just have to live without some of the ES6 features. Personally, I'm a big fan of Go (old C++ programmer). We started using it a little over 2 years ago. The language definition has changed in that time, so I wouldn't call it stable ;-) The core libraries are rock solid, though. We barely use any 3rd party libraries (I think we use 2) so it's not really fair to compare that with other languages. Although we have a fair amount of python in our shop, I don't seem to work on those projects very much (a month here and there). I can't say too much about it other than our Python code breaks due to 3rd party libraries more often than any of our other code. However, I think this is probably due to injudicious choices for our 3rd party libraries ;-) Overall, I would say that my experiences don't match yours, but I wonder if it's because we never tried moving to IO.

by dcwca 11y ago

blowski 11y ago

Anything. I'm a pragmatic developer who just wants solutions that help me pay the bills. It's precisely for that reason that Node has been a problem for me - it's caused much more than its fair share of headaches, when compared to Ruby, Python, PHP, Bash, Go. Perhaps using a framework would make things easier, but I'm reticent to rely on it in the main part of the project when it causes so many problems just in the small parts.

nilliams 11y ago
Can you give an actual example of the 'so many problems' you describe? Your previous comments address the paradox-of-choice idea, but the uncontroversial path in Node is to 'just use Express' right? How it that a worse situation than in other languages where there are also trendy frameworks competing against the default option. You name PHP as a better situation but from what I gather PHP is even worse at casting off legacy frameworks. Laravel is the new trendy, whereas it was CodeIgniter/Symphony before that and EE/Wordpress before that. And in Ruby, there's similar competition over an alternative to Rails [0]. [0] https://blog.engineyard.com/2015/life-beyond-rails-brief-look-alternate-web-frameworks-ruby https://blog.engineyard.com/2015/life-beyond-rails-brief-loo...
- blowski 11y ago
  Sure. There was the decision a couple of years back to stop using self signed certificates. I spent a couple of hours wondering why a server I was running that compiled SASS on deployment suddenly stopped working, and it turned out to have been this. A more recent example comes from Zombie, which I use for functional testing. When they moved to v3, they required io.js instead of Node. So eventually I decided to go with Zombie 3 and moved to io.js, but then another library broke which required Node instead of io.js. They're the two big ones that stand out, but there have been lots of other small annoyances.
  - brazzledazzle 11y ago
    I don't have a dog in this fight but the certificate thing sounds a lot like they corrected a significant security issue rather than API instability.
    - blowski 11y ago
      True enough, but they didn't tell anyone they'd done it for hours after they pushed out the changes. A notice on the terminal after the update should have been possible, or at least a big message on the homepage. But nothing - only an angry GitHub issues queue with random suggested causes and fixes.
notNow 11y ago
Software development is not about chasing the latest shiny fad or trend on the market, it's about solving real-world problems by researching available solutions. So, if you think that Node doesn't fit or not equipped enough to solve your problems, you're welcome to check other solutions till you find the one most suitable to the problem at hand. So, if you think that Ruby or Python could get things done for you and you're very familiar with them, go for either and get it done but to pick on Node just because you don't quite grasp its inner workings is really odd of you and the whole reasoning behind your critique is rather absurd.
- blowski 11y ago
  It's not absurd to say "I'd like to use Node because of its performance and because it's easier to hire for, but only if it were more stable and had better documentation". As somebody who has to consider trade-offs between short-term and long-term costs for clients, these are very real problems for me.
  - Touche 11y ago
    Node's documentation really is terrible. The fact that it doesn't show what arguments functions take, what types are expected, etc. is pretty sad in 2015. The documentation is barely better than your typical side-project readme.md file, at best you get 1 example of an api's usage (always the most basic use-case only, of course).
- drumdance 11y ago
  Preach. I inherited a Node project for which Rails was a much better solution for our use case. It's been fun learning a new platform, but for our needs Rails would have been fine. The only conceivable reason I can see they chose Node is because it's cool.
mikekchar 11y ago
In our shop we actually use all of Ruby, Node, Go, Python and Bash (in about that order of code volume). Honestly, for instability of 3rd party libraries Node is pretty bad, but Ruby is not really far behind. I am sure that I have spent more time debugging other people's code in Ruby than in Javascript. Having said that the IO split has been a royal PITA. We got pegged to Node 10.x because JSDom only supports IO and Jest (which is what we wanted JSDom for) only supports Node :-P. I've been waiting a year for it to get cleared up. It sounds like we made the right choice, though, because in this thread the people who are complaining about Node seem to be the ones who tried switching back and forth between IO and Node. There is actually only one bug in Node that has impacted me (related to the way connections are shut down) and it isn't fixed yet in master so not upgrading hasn't really impacted us. We just have to live without some of the ES6 features. Personally, I'm a big fan of Go (old C++ programmer). We started using it a little over 2 years ago. The language definition has changed in that time, so I wouldn't call it stable ;-) The core libraries are rock solid, though. We barely use any 3rd party libraries (I think we use 2) so it's not really fair to compare that with other languages. Although we have a fair amount of python in our shop, I don't seem to work on those projects very much (a month here and there). I can't say too much about it other than our Python code breaks due to 3rd party libraries more often than any of our other code. However, I think this is probably due to injudicious choices for our 3rd party libraries ;-) Overall, I would say that my experiences don't match yours, but I wonder if it's because we never tried moving to IO.