4 ms·

I agree with this article and find the Node.js community, and to a lesser extent Javascript itself, exhausting. It seems like every 2 minutes there is a "more"

by Corrado 11y ago

I agree with this article and find the Node.js community, and to a lesser extent Javascript itself, exhausting. It seems like every 2 minutes there is a "more" proper way to do something, which tells me that the architecture is not yet mature, even though it's pretty old by now. On a related note, it seems like every time you find something that doesn't quite work correctly or conveniently in Node.js there is a "fix". Don't like callbacks? Force Node.js to look more like other "normal" code and use Promises. Having trouble getting Node.js to concentrate on one thing at a time? Force Node.js to look more like other "normal" languages and use the "async" library. And it just goes on and on and on. If I have to use all of these other pieces and parts to be productive in Node.js I may as well just use some other language. I really wanted to like and use Node.js, but Javascript and the community are holding it back.

Kequc 11y ago
I'm still not all the way on board with promises - from the sounds of it this article says there is already a successor down the pipe. As you've pointed out some of these libraries make things behave a lot more similarly to other languages. And in such a case you may be better off just using one of them. However you're giving up on a lot of the power and benefits javascript provides, so of course you'd want to use something else. For all of its pitfalls and annoyances, javascript is too powerful a language to ignore. Asynchronous operations and streams are just too good. They are difficult to balance but once mastered you can really do a lot with them. My recommendation would be to skip libraries where possible. Use raw ES6, or Typescript. Something javascript has been suffering from for a long time is bloat from external libraries. You don't really need to use them, especially now that the language has more or less settled down. All of the best libraries were used to normalise things and that's not really needed anymore.
- MichaelGG 11y ago
  How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?
  - kalms 11y ago
    I think it's more a matter of it being the only way to get things done in JavaScript and Node.js specifically (an overstatement, but that seems to be the sentiment).
  - Kequc 11y ago
    When javascript performs an asynchronous operation it doesn't block the thread. It stacks everything on a queue and then just works through everything as fast as possible. Any other language would require a separate thread for each operation. I'm sure there's one other language out there that does it too but I don't know what it is. Event based programming effectively means that as long as it has something to do it's doing it. You tell it to wait? It says great I've got all this other stuff to do. Streams you may have me there, I didn't realise those were so widely used in other languages. Javascript works pretty well because you can run it on the whole stack. Share code between the front and back end. Stream from one place to another and around the corner.
    - pathsjs 11y ago
      Python, Scala, OCaml, Nim, Haskell and more all have asynchronous operations for I/O - it's not something that is a JS only thing
    - beders 11y ago
      Vert.x basically gives you everything that node.js has - and it spins up several event loops, making your code scale without having to run several node processes. It also allows you to mix in worker threads that are allowed to block (for I/O, for example). You can develop in JavaScript, Java, Ruby, Ceylon, Groovy. It's fast, async and robust.
  - Klathmon 11y ago
    Personally I just like that things are async by default. That means that if you are using a 3rd party library, it will be async from the start. In something like python you need to work to get a fully async app, but in node you should file bugs if something blocks on IO.
eagsalazar2 11y ago
Yes, the Javascript world is quickly evolving both on the front end and backend, and of course that can be exhausting but I have to disagree with both conclusions that (a) this means the tech is immature, and (b) the community's readiness to make changes is "holding it back". The js world is very unique in its ability to evolve quickly and things have improved massively over the last few years. Now, apart from the churn itself and precisely because of that rapid evolution, front end and backend development in javascript is amazing compared to most other options (especially on the front end). So while you do have to be realistic about the cost of the evolving ecosystem, it is just a tradeoff for rapid progress, not a flaw. If you crave stability, agreed, this rollercoaster probably isn't your ride. But the evolution of node, the emergence of react/redux, es6, etc is amazing and beautiful IMO and I'm totally enjoying every bit of it compared to the staid mediocrity of my Rails, C/C++, and Java history.
- rimantas 11y ago
  The problem I see that in this case "evolving" looks suspiciously like running in circles without going anywhere.
  - royjacobs 11y ago
    A good example mentioned in the article is the "npm scripts -> grunt -> gulp -> npm scripts" evolution in best practices for building.
- Corrado 11y ago
  I'm not saying that Node.js is bad and shouldn't be used. Rails was in the exact same boat several years ago; everything was changing so quickly that new people on the scene had to work pretty hard to keep up. Being on the other side of that process with Node.js, I can now understand the Rails newbie's frustration. :) If you are comfortable with the constant change and evolution in a platform/language/framework, then by all means continue to use it. Just don't disparage people that come forward and point out the pains they have and say that everything is fine. Just my $0.02.

by Corrado 11y ago

Kequc 11y ago

I'm still not all the way on board with promises - from the sounds of it this article says there is already a successor down the pipe. As you've pointed out some of these libraries make things behave a lot more similarly to other languages. And in such a case you may be better off just using one of them. However you're giving up on a lot of the power and benefits javascript provides, so of course you'd want to use something else. For all of its pitfalls and annoyances, javascript is too powerful a language to ignore. Asynchronous operations and streams are just too good. They are difficult to balance but once mastered you can really do a lot with them. My recommendation would be to skip libraries where possible. Use raw ES6, or Typescript. Something javascript has been suffering from for a long time is bloat from external libraries. You don't really need to use them, especially now that the language has more or less settled down. All of the best libraries were used to normalise things and that's not really needed anymore.

MichaelGG 11y ago
How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?
- kalms 11y ago
  I think it's more a matter of it being the only way to get things done in JavaScript and Node.js specifically (an overstatement, but that seems to be the sentiment).
- Kequc 11y ago
  When javascript performs an asynchronous operation it doesn't block the thread. It stacks everything on a queue and then just works through everything as fast as possible. Any other language would require a separate thread for each operation. I'm sure there's one other language out there that does it too but I don't know what it is. Event based programming effectively means that as long as it has something to do it's doing it. You tell it to wait? It says great I've got all this other stuff to do. Streams you may have me there, I didn't realise those were so widely used in other languages. Javascript works pretty well because you can run it on the whole stack. Share code between the front and back end. Stream from one place to another and around the corner.
  - pathsjs 11y ago
    Python, Scala, OCaml, Nim, Haskell and more all have asynchronous operations for I/O - it's not something that is a JS only thing
  - beders 11y ago
    Vert.x basically gives you everything that node.js has - and it spins up several event loops, making your code scale without having to run several node processes. It also allows you to mix in worker threads that are allowed to block (for I/O, for example). You can develop in JavaScript, Java, Ruby, Ceylon, Groovy. It's fast, async and robust.
- Klathmon 11y ago
  Personally I just like that things are async by default. That means that if you are using a 3rd party library, it will be async from the start. In something like python you need to work to get a fully async app, but in node you should file bugs if something blocks on IO.

eagsalazar2 11y ago

Yes, the Javascript world is quickly evolving both on the front end and backend, and of course that can be exhausting but I have to disagree with both conclusions that (a) this means the tech is immature, and (b) the community's readiness to make changes is "holding it back". The js world is very unique in its ability to evolve quickly and things have improved massively over the last few years. Now, apart from the churn itself and precisely because of that rapid evolution, front end and backend development in javascript is amazing compared to most other options (especially on the front end). So while you do have to be realistic about the cost of the evolving ecosystem, it is just a tradeoff for rapid progress, not a flaw. If you crave stability, agreed, this rollercoaster probably isn't your ride. But the evolution of node, the emergence of react/redux, es6, etc is amazing and beautiful IMO and I'm totally enjoying every bit of it compared to the staid mediocrity of my Rails, C/C++, and Java history.

rimantas 11y ago
The problem I see that in this case "evolving" looks suspiciously like running in circles without going anywhere.
- royjacobs 11y ago
  A good example mentioned in the article is the "npm scripts -> grunt -> gulp -> npm scripts" evolution in best practices for building.
Corrado 11y ago
I'm not saying that Node.js is bad and shouldn't be used. Rails was in the exact same boat several years ago; everything was changing so quickly that new people on the scene had to work pretty hard to keep up. Being on the other side of that process with Node.js, I can now understand the Rails newbie's frustration. :) If you are comfortable with the constant change and evolution in a platform/language/framework, then by all means continue to use it. Just don't disparage people that come forward and point out the pains they have and say that everything is fine. Just my $0.02.