4 ms·

> 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

by 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.
    - imagist 10y ago
      > I am not really familiar with how to deploy Node in production, having never done so, Maybe don't form uneducated opinions on things you don't have any experience with, then.
      - geofft 10y ago
        I phrased it that way to be polite, but if you're not interested: I know that these tools exist. I was giving you an opportunity to save face for your uneducated and factually incorrect claims. The left-pad incident broke CI tools that intentionally referenced public NPM, not competent internal deployments. It broke incompetent internal deployments, yes, but every other language ecosystem can be deployed incompetently. If you're relying on the availability and correctness of a public service for deployments, whether or not it's signed or allows packages to be removed, you're doing it wrong. This is as true for NPM as it is for Debian.
        imagist 10y ago
        > I phrased it that way to be polite, Unless you were just outright lying, not having ever deployed Node in production isn't just being polite, it's literally admitting you have no practical knowledge of the technology you're defending. I can see some value in the feedback of someone who has only worked with Node 3 months or so--newcomer reactions give some impression of the learning curve of the technology, which matters. But you've done what, read a blog post? Your opinion on this subject is worthless. > I know that these tools exist. As do I, and what's more, I've used those tools. > I was giving you an opportunity to save face for your uneducated and factually incorrect claims. Which ones were those exactly? > The left-pad incident broke CI tools that intentionally referenced public NPM, not competent internal deployments. It broke incompetent internal deployments, yes, but every other language ecosystem can be deployed incompetently. Yes, you can use NPM shrinkwrap (and I do) but let's be clear: that means you get to devote perhaps a week out of every year updating everything manually. "Competent" deployments with NPM involve enough of a pain in the ass that, after a few years of doing this, I'd actually prefer to manually import dependencies. But that's not really a viable option. If you're going to claim this is just incompetence, I am inclined to agree with you. But that means that an inordinate portion of the Node community is incompetent, so I'm not sure this can be represented as a defense of Node. > If you're relying on the availability and correctness of a public service for deployments, whether or not it's signed or allows packages to be removed, you're doing it wrong. If that's the case, then I don't know of ANYONE who is using NPM correctly, because to avoid relying on whether or not things are signed, you'd have to audit literally everything pulled down by NPM, which even for simple projects can be half a million lines of code. Shrinkwrap means you only have to do it once, but that's still more time than anyone I know of has.

by imagist 10y ago

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.
  - imagist 10y ago
    > I am not really familiar with how to deploy Node in production, having never done so, Maybe don't form uneducated opinions on things you don't have any experience with, then.
    - geofft 10y ago
      I phrased it that way to be polite, but if you're not interested: I know that these tools exist. I was giving you an opportunity to save face for your uneducated and factually incorrect claims. The left-pad incident broke CI tools that intentionally referenced public NPM, not competent internal deployments. It broke incompetent internal deployments, yes, but every other language ecosystem can be deployed incompetently. If you're relying on the availability and correctness of a public service for deployments, whether or not it's signed or allows packages to be removed, you're doing it wrong. This is as true for NPM as it is for Debian.
      - imagist 10y ago
        > I phrased it that way to be polite, Unless you were just outright lying, not having ever deployed Node in production isn't just being polite, it's literally admitting you have no practical knowledge of the technology you're defending. I can see some value in the feedback of someone who has only worked with Node 3 months or so--newcomer reactions give some impression of the learning curve of the technology, which matters. But you've done what, read a blog post? Your opinion on this subject is worthless. > I know that these tools exist. As do I, and what's more, I've used those tools. > I was giving you an opportunity to save face for your uneducated and factually incorrect claims. Which ones were those exactly? > The left-pad incident broke CI tools that intentionally referenced public NPM, not competent internal deployments. It broke incompetent internal deployments, yes, but every other language ecosystem can be deployed incompetently. Yes, you can use NPM shrinkwrap (and I do) but let's be clear: that means you get to devote perhaps a week out of every year updating everything manually. "Competent" deployments with NPM involve enough of a pain in the ass that, after a few years of doing this, I'd actually prefer to manually import dependencies. But that's not really a viable option. If you're going to claim this is just incompetence, I am inclined to agree with you. But that means that an inordinate portion of the Node community is incompetent, so I'm not sure this can be represented as a defense of Node. > If you're relying on the availability and correctness of a public service for deployments, whether or not it's signed or allows packages to be removed, you're doing it wrong. If that's the case, then I don't know of ANYONE who is using NPM correctly, because to avoid relying on whether or not things are signed, you'd have to audit literally everything pulled down by NPM, which even for simple projects can be half a million lines of code. Shrinkwrap means you only have to do it once, but that's still more time than anyone I know of has.