7 ms·

It's telling that none of the posts defending Node.js are talking about it's technical merits. They're all saying: 1. Attacks on people--you're being too negat

by imagist 10y ago

It's telling that none of the posts defending Node.js are talking about it's technical merits. They're all saying: 1. Attacks on people--you're being too negative, you're saying this to feel superior. 2. Choosing Node.js is a tradeoff! We can't really say what you get in exchange for using this crappy ecosystem, but "tradeoff" sounds good even if you're trading using a reasonable ecosystem for nothing. If you really think Node.js isn't a flaming pile of crap, I challenge you to come up with something it does that isn't done far better in another ecosystem.

geofft 10y ago
> I challenge you to come up with something it does that isn't done far better in another ecosystem. A single, standard event loop that literally every library in the ecosystem uses so you don't have to worry about it. The other options are compiled languages (Windows message pump, Qt or GTK+ event loop, etc.), which aren't what people seem to want for Node's use case, or things like Twisted. For all of those options other than maybe Windows, you don't get to assume that the entire ecosystem speaks the same event loop protocol. And I don't think any of these options do it far better than Node does. Twisted is pretty good, probably a little better, but Node is just fine too. Note that I am not a Node.js programmer. I can kind of work with existing apps in Node because I can kind of write JS sometimes (I'm really more of a C person). I just know what other technologies are good at.
- PeCaN 10y ago
  > A single, standard event loop that literally every library in the ecosystem uses so you don't have to worry about it. Tcl? Erlang/OTP?
- imagist 10y ago
  > A single, standard event loop that literally every library in the ecosystem uses so you don't have to worry about it. Using an event loop with all the other threading models available out there is like bringing a knife to a gunfight. I could maybe argue that JavaScript's event loop isn't as good as other event loops, but while actor models exist, I'm not sure why we'd even talk about event loops.
  - geofft 10y ago
    Actor models don't solve the problem of getting a good-sized ecosystem going. If you have production-ready actor-model libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing. (Maybe that's a failure of listening on my part!) If you want to develop that ecosystem, awesome, and I totally support that. But I would much rather bring a knife to a gunfight than some totally awesome, straight-from-the-laboratory gun that's never been tested in combat.
    - imagist 10y ago
      > If you have production-ready actor-model libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing. If you have production-ready event loop libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing. Part of the problem with the Node ecosystem is that the bar for "production ready" is very, very low. For example, literally nothing in NPM is production ready where security matters, because the package system is fundamentally insecure. left-pad broke builds everywhere--what if instead of failing to download, it introduced a backdoor? And even if you assume all the randos who maintain NPM packages are trustworthy, there's no signature verification on code, so any of them could have their accounts compromised and there would be no way to tell. This is the code you want me to run on my server? Really? Node has a large ecosystem, but the subset of Node's ecosystem which is actually quality software is quite small. > But I would much rather bring a knife to a gunfight than some totally awesome, straight-from-the-laboratory gun that's never been tested in combat. Me too, but I'm exceedingly surprised to hear you quote this as a positive of Node.
      - geofft 10y ago
        I am not really familiar with how to deploy Node in production, having never done so, but aren't there relatively easy ways to mirror NPM locally? Or can't you just check node_modules into version control (possibly a separate branch or something)? Honestly if I had to deploy Node in production I'd be inclined to see if I can just use those Node libraries that are packaged for Debian. I do the same thing for deploying Python, Perl, C, etc. in production.
pavlov 10y ago
Yours is not a technical argument either -- you're just pre-emptively claiming that no counterargument can be valid.
- imagist 10y ago
  No, a technical counterargument could be valid if Node had any technical merit. I'm claiming that no valid technical counterargument exists. If you disagree, it should be very easy for you to present a valid technical counterargument instead of trying to offload the burden of proof onto me.
  - pavlov 10y ago
    geofft's reply to your grandparent comment is a valid counterargument IMO. I noticed your reply, which is basically "nobody should be using an event loop". Whether you like it or not, that's how 99.99% of the GUI software in existence works (Win32, Cocoa, whatever). Node allows people to leverage their existing mental model into server apps.
    - imagist 10y ago
      Global event loops are fundamentally a bad abstraction for a parallel (not just concurrent) system. It makes sense to leverage existing mental models in a lot of cases, but when you're moving to a new platform, you have to learn some new mental models because your existing mental model fundamentally doesn't work in the new system. Global event loops don't work, at all, in a system that actually needs to be parallel (i.e. most server systems). Giving up on writing software that scales even to a basic level just so you can reuse your existing mental model isn't a good tradeoff.
    - toupeira 10y ago
      But UI's have to be async if they want to be responsive, while the HTTP request-response cycle (which is what Node is predominantly used for) is completely synchronous. Sure, things like WebSockets are changing this, but you don't really need an event loop if you have proper threads or a multi-process server (you know, like Node clustering, which you tend to need anyway once you outgrow the limits and pains of a single event loop).
garysieling 10y ago
There are some impressive libraries in the Node ecosystem. As an example, passportjs gives you support for a lot of weirdly custom OAuth implementations, Kerberos, etc
- 0xfaded 10y ago
  ispositivenumber.js Wait, there's also is-positive-number.js So confused
  - hexasquid 10y ago
    The JavaScript community really needs to get together and fix it so only one version of any possible library is published.
- imagist 10y ago
  Passport JS is horrible. Sure it's easy to use, but it's not secure, which is kind of the entire point. There are other libraries that are interesting, but that's more a function of necessity than of it being a good thing--people write JavaScript because it's the only thing that runs on the browser, and then people port it onto Node. And it's worth noting that a lot of these have been held back significantly by being on Node. Take Babel for example; it's useful and interesting, but the code is a mess because of callbacks, which makes it hard to modify, and it was taken down by the left-pad fiasco a few months back (which broke thousands and thousands of builds worldwide). Some interesting things have been built on Node, but that's despite Node, not because of Node, and they would be more reliable if they weren't built on Node.
  - garysieling 10y ago
    Yeah, that's fair. I can't say I've used it beyond prototyping, for which it is very easy. I came across it vs. doing something similar in C#, which required one library per vendor (Quickbooks OAuth, Google OAuth etc), and when I last used them I ran into issues where they conflicted so I like the combined interface approach.
HeavyStorm 10y ago
I've been working on a project that uses node for the better part of the year. I'm in charge of most of its architecture and design. After all these months, my conclusion is exactly the same as yours: there's nothing that can be done in done that I can't do better in other platform/ecosystem. Sure, it's unique (event loop) and has a lot of good things (simplicity), but for anything serious, it's lacking real advantages. Most of my issues with it comes with javascript itself, and the absence of proper tooling. I have no idea of the advantage of choosing this platform given the level of immaturity. Oh, for those wondering: Node was chosen by a person caught on the hype (my boss, a friend and mentor who can make mistakes as anyone), who hadn't done any real world programming in it (only hello world stuff).
- erlich 10y ago
  > Most of my issues with it comes with javascript itself, and the absence of proper tooling. Does anything in ES2017, FlowType, or TypeScript resolve your issues with Javascript itself? If not, what are the three biggest? > absence of proper tooling What do you mean by proper tooling? What are you comparing it to? I think you might find that many of the other modern options also lack tooling in terms of debugging, IDE support, etc.
  - blakeyrat 10y ago
    Right; but C# does everything Node.JS does easier and faster (even the event loop, if you like, although it also has first-class support for threading), and has excellent IDEs, debuggers, documentation generators, etc.
    - erlich 10y ago
      Ah yes, C# has awesome tooling. I thought you were comparing to something like Go.
erlich 10y ago
> isn't a flaming pile of crap The hyperbole in every criticism of Node must be there for a reason. I think it is more a reflection on the state of mind of the critic rather than the language. I would posit that many have dedicated huge amounts of time to a new or less-popular language that may not be around in 5 years. JS is a safe, long-term bet. It's tentacles have made it into every platform and use case out there. Backend, frontend, embedded, mobile, desktop, etc. I'm curious, what does your vision of the future of web and mobile development look like? Which language do you wish was in browsers instead of JS? How would you objectively rank what makes a "good" language and a "crap" language, and how would you test these hypotheses?
- Ar-Curunir 10y ago
  JS is not a safe long term bet if you want to build reliable systems. There are better languages out there for this purpose. Just because JS is widespread does not mean it is good.
- imagist 10y ago
  > The hyperbole in every criticism of Node must be there for a reason. I think it is more a reflection on the state of mind of the critic rather than the language. "It's telling that none of the posts defending Node.js are talking about it's technical merits. They're all saying: 1. Attacks on people--you're being too negative, you're saying this to feel superior." > JS is a safe, long-term bet. It's tentacles have made it into every platform and use case out there. Backend, frontend, embedded, mobile, desktop, etc. By that argument, Java is a better language than JavaScript. There are a lot of established languages that aren't going anywhere. And certainly with WebAssembly in the works, I'm not as confident that JS will be popular in two decades as you are.
  - erlich 10y ago
    Agree that WebAssembly is the big one to watch. On the prior point, from my experience there is a big confirmation bias at work and I think these discussions would go better if there was some disclosure of how invested each person was in their own language of choice. E.g. if you realised you could ship features faster in language X, how much wasted time would you have invested in language Y. When I was working all Scala, I was always looking to confirm my decision by reading positive reviews, reading about the switchers from Ruby, because I was spending huge amounts of time learning it. This was right up until the point that I switched to Node and could ship features 10x faster. I think people are always happy to read articles like this and see people switching away from Node if they are working in something trendy like Go. It feels good. But at some level there is a fear that the thousands of hours you spend on learning the intricacies of a language may be wasted.

by imagist 10y ago

geofft 10y ago

> I challenge you to come up with something it does that isn't done far better in another ecosystem. A single, standard event loop that literally every library in the ecosystem uses so you don't have to worry about it. The other options are compiled languages (Windows message pump, Qt or GTK+ event loop, etc.), which aren't what people seem to want for Node's use case, or things like Twisted. For all of those options other than maybe Windows, you don't get to assume that the entire ecosystem speaks the same event loop protocol. And I don't think any of these options do it far better than Node does. Twisted is pretty good, probably a little better, but Node is just fine too. Note that I am not a Node.js programmer. I can kind of work with existing apps in Node because I can kind of write JS sometimes (I'm really more of a C person). I just know what other technologies are good at.

PeCaN 10y ago
> A single, standard event loop that literally every library in the ecosystem uses so you don't have to worry about it. Tcl? Erlang/OTP?
imagist 10y ago
> A single, standard event loop that literally every library in the ecosystem uses so you don't have to worry about it. Using an event loop with all the other threading models available out there is like bringing a knife to a gunfight. I could maybe argue that JavaScript's event loop isn't as good as other event loops, but while actor models exist, I'm not sure why we'd even talk about event loops.
- geofft 10y ago
  Actor models don't solve the problem of getting a good-sized ecosystem going. If you have production-ready actor-model libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing. (Maybe that's a failure of listening on my part!) If you want to develop that ecosystem, awesome, and I totally support that. But I would much rather bring a knife to a gunfight than some totally awesome, straight-from-the-laboratory gun that's never been tested in combat.
  - imagist 10y ago
    > If you have production-ready actor-model libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing. If you have production-ready event loop libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing. Part of the problem with the Node ecosystem is that the bar for "production ready" is very, very low. For example, literally nothing in NPM is production ready where security matters, because the package system is fundamentally insecure. left-pad broke builds everywhere--what if instead of failing to download, it introduced a backdoor? And even if you assume all the randos who maintain NPM packages are trustworthy, there's no signature verification on code, so any of them could have their accounts compromised and there would be no way to tell. This is the code you want me to run on my server? Really? Node has a large ecosystem, but the subset of Node's ecosystem which is actually quality software is quite small. > But I would much rather bring a knife to a gunfight than some totally awesome, straight-from-the-laboratory gun that's never been tested in combat. Me too, but I'm exceedingly surprised to hear you quote this as a positive of Node.
    - geofft 10y ago
      I am not really familiar with how to deploy Node in production, having never done so, but aren't there relatively easy ways to mirror NPM locally? Or can't you just check node_modules into version control (possibly a separate branch or something)? Honestly if I had to deploy Node in production I'd be inclined to see if I can just use those Node libraries that are packaged for Debian. I do the same thing for deploying Python, Perl, C, etc. in production.

pavlov 10y ago

Yours is not a technical argument either -- you're just pre-emptively claiming that no counterargument can be valid.

imagist 10y ago
No, a technical counterargument could be valid if Node had any technical merit. I'm claiming that no valid technical counterargument exists. If you disagree, it should be very easy for you to present a valid technical counterargument instead of trying to offload the burden of proof onto me.
- pavlov 10y ago
  geofft's reply to your grandparent comment is a valid counterargument IMO. I noticed your reply, which is basically "nobody should be using an event loop". Whether you like it or not, that's how 99.99% of the GUI software in existence works (Win32, Cocoa, whatever). Node allows people to leverage their existing mental model into server apps.
  - imagist 10y ago
    Global event loops are fundamentally a bad abstraction for a parallel (not just concurrent) system. It makes sense to leverage existing mental models in a lot of cases, but when you're moving to a new platform, you have to learn some new mental models because your existing mental model fundamentally doesn't work in the new system. Global event loops don't work, at all, in a system that actually needs to be parallel (i.e. most server systems). Giving up on writing software that scales even to a basic level just so you can reuse your existing mental model isn't a good tradeoff.
  - toupeira 10y ago
    But UI's have to be async if they want to be responsive, while the HTTP request-response cycle (which is what Node is predominantly used for) is completely synchronous. Sure, things like WebSockets are changing this, but you don't really need an event loop if you have proper threads or a multi-process server (you know, like Node clustering, which you tend to need anyway once you outgrow the limits and pains of a single event loop).

garysieling 10y ago

There are some impressive libraries in the Node ecosystem. As an example, passportjs gives you support for a lot of weirdly custom OAuth implementations, Kerberos, etc

0xfaded 10y ago
ispositivenumber.js Wait, there's also is-positive-number.js So confused
- hexasquid 10y ago
  The JavaScript community really needs to get together and fix it so only one version of any possible library is published.
imagist 10y ago
Passport JS is horrible. Sure it's easy to use, but it's not secure, which is kind of the entire point. There are other libraries that are interesting, but that's more a function of necessity than of it being a good thing--people write JavaScript because it's the only thing that runs on the browser, and then people port it onto Node. And it's worth noting that a lot of these have been held back significantly by being on Node. Take Babel for example; it's useful and interesting, but the code is a mess because of callbacks, which makes it hard to modify, and it was taken down by the left-pad fiasco a few months back (which broke thousands and thousands of builds worldwide). Some interesting things have been built on Node, but that's despite Node, not because of Node, and they would be more reliable if they weren't built on Node.
- garysieling 10y ago
  Yeah, that's fair. I can't say I've used it beyond prototyping, for which it is very easy. I came across it vs. doing something similar in C#, which required one library per vendor (Quickbooks OAuth, Google OAuth etc), and when I last used them I ran into issues where they conflicted so I like the combined interface approach.

HeavyStorm 10y ago

I've been working on a project that uses node for the better part of the year. I'm in charge of most of its architecture and design. After all these months, my conclusion is exactly the same as yours: there's nothing that can be done in done that I can't do better in other platform/ecosystem. Sure, it's unique (event loop) and has a lot of good things (simplicity), but for anything serious, it's lacking real advantages. Most of my issues with it comes with javascript itself, and the absence of proper tooling. I have no idea of the advantage of choosing this platform given the level of immaturity. Oh, for those wondering: Node was chosen by a person caught on the hype (my boss, a friend and mentor who can make mistakes as anyone), who hadn't done any real world programming in it (only hello world stuff).

erlich 10y ago
> Most of my issues with it comes with javascript itself, and the absence of proper tooling. Does anything in ES2017, FlowType, or TypeScript resolve your issues with Javascript itself? If not, what are the three biggest? > absence of proper tooling What do you mean by proper tooling? What are you comparing it to? I think you might find that many of the other modern options also lack tooling in terms of debugging, IDE support, etc.
- blakeyrat 10y ago
  Right; but C# does everything Node.JS does easier and faster (even the event loop, if you like, although it also has first-class support for threading), and has excellent IDEs, debuggers, documentation generators, etc.
  - erlich 10y ago
    Ah yes, C# has awesome tooling. I thought you were comparing to something like Go.

erlich 10y ago

> isn't a flaming pile of crap The hyperbole in every criticism of Node must be there for a reason. I think it is more a reflection on the state of mind of the critic rather than the language. I would posit that many have dedicated huge amounts of time to a new or less-popular language that may not be around in 5 years. JS is a safe, long-term bet. It's tentacles have made it into every platform and use case out there. Backend, frontend, embedded, mobile, desktop, etc. I'm curious, what does your vision of the future of web and mobile development look like? Which language do you wish was in browsers instead of JS? How would you objectively rank what makes a "good" language and a "crap" language, and how would you test these hypotheses?

Ar-Curunir 10y ago
JS is not a safe long term bet if you want to build reliable systems. There are better languages out there for this purpose. Just because JS is widespread does not mean it is good.
imagist 10y ago
> The hyperbole in every criticism of Node must be there for a reason. I think it is more a reflection on the state of mind of the critic rather than the language. "It's telling that none of the posts defending Node.js are talking about it's technical merits. They're all saying: 1. Attacks on people--you're being too negative, you're saying this to feel superior." > JS is a safe, long-term bet. It's tentacles have made it into every platform and use case out there. Backend, frontend, embedded, mobile, desktop, etc. By that argument, Java is a better language than JavaScript. There are a lot of established languages that aren't going anywhere. And certainly with WebAssembly in the works, I'm not as confident that JS will be popular in two decades as you are.
- erlich 10y ago
  Agree that WebAssembly is the big one to watch. On the prior point, from my experience there is a big confirmation bias at work and I think these discussions would go better if there was some disclosure of how invested each person was in their own language of choice. E.g. if you realised you could ship features faster in language X, how much wasted time would you have invested in language Y. When I was working all Scala, I was always looking to confirm my decision by reading positive reviews, reading about the switchers from Ruby, because I was spending huge amounts of time learning it. This was right up until the point that I switched to Node and could ship features 10x faster. I think people are always happy to read articles like this and see people switching away from Node if they are working in something trendy like Go. It feels good. But at some level there is a fear that the thousands of hours you spend on learning the intricacies of a language may be wasted.