4 ms·

I think it is ok to express displeasure at the state of something without just silently doing something else and hoping that the entire ecosystem catches up to

I think it is ok to express displeasure at the state of something without just silently doing something else and hoping that the entire ecosystem catches up to you. For example, I take every opportunity (like right now, for example) to shit on node.js and npm for that very reason. There is so much evangelism on one side, it is nice to hear the opposing view points.

sillysaurus3 9y ago
Ok, so what are some legit criticisms of node.js and npm? I'm no fanboy, but every time I try to ask this, the answers are along the lines of "if you install packages in a different order, you get different results." Which is fair, but everybody installs using `npm i`, so that's mostly a moot point. Is there any substance here? I think it's fair to talk about this, as long as we go out of our way not to reduce it to flamewar territory. The app is built on Electron, after all. Maybe avoid mentioning memory usage, since that point has been done to death.
- Jach 9y ago
  What counts as a legit criticism? So much of our field is taste-driven. And so much criticism was aimed at old iterations of something, gets carried on in flamewars, but no longer applies to the latest version (e.g. "Java is slow"). All the JS-the-language criticisms apply, those are probably the biggest at this point. The classic "node.js is cancer" is still somewhat relevant though I never thought it made its point well enough on how forced-asynchronous is at least as bad as the forced OOP and checked exceptions we put up with in e.g. Java again. Callback hell was long a common complaint, until people found Promises / the waterfall structure, but then the complaint is debugging hell. The new await stuff in node 8 sounds nice at least. For a long time npm didn't get stuff over https by default, I think it does for a year now? The only other criticisms I can think of are just shoddy engineering that turns into drama (I remember seeing something about their colorized output would slow everything down quite a lot) or more taste-level things like how seemingly trivial concepts like leftpad are core libraries (that go through multiple versions because it couldn't have just been done right the first time) and the drama involved when something everyone depends on has an issue. Disclaimer, I haven't done production node since ~2013. It was actually mostly enjoyable, and I wouldn't mind doing it again, despite on the taste-level I think the whole node ecosystem is just worse than many other options (when you have a choice) for many specific problems. But life is a continuous lesson in Worse is Better.
- mhuffman 9y ago
  > Ok, so what are some legit criticisms of node.js and npm? I am glad you asked! You know how everyone runs to circle-jerk the praise "use the right tool for the job"? Well, Javascript is NEVER the right answer when the "job" is business logic or systems development or almost anything else. But here we are. Do you know why people think Javascript is fucking cancer? Because it was developed to animate visitor counters and help with animated menu and resize issues that css wasn't up to at the time. It doesn't have strong types and rigid structure because it was created to be a language that assists your browser in little ways. So a little more history is in order. Along comes Microsoft and creates XMLHttpRequest which could offer a "real-time" feel to some websites, and it was awesome! This was the first horseman of the apocalypse. Then Google blew everyone's fucking minds with google maps (inc. google earth) and gmail. And was basically single-handedly responsible for the Web 2.0 (single-page app) explosion...and the second horse of the apocalypse. Javascript grew and metastasized in every way imaginable, because everyone felt that single-page apps were exactly what they needed for their new toilet-sharing app idea, and so it went. Then one dark day Node.js emerged from is leathery egg and blew everyone's fucking mind again with what could be done when you get a genius to abuse the javascript engine for entertainment. And the worst pale horse of the apocalypse rode forth. For, you see, now webpage developers who know two days worth of shitty Javascript could now call themselves "full-stack developers". And oh my fucking god did they develop! Every afterbirth of an idea was haphazardly put together into a short script and posted to blow everyones fucking minds with how awesome their new 1,000-line sentence capitalization script was. Now with this torrent of javascript libraries from all the new developers that didn't know they were developers but totally were, came a problem. How could we get all of the diarrhea into everyone's mouths as efficiently as possible? I mean how are you going to write your single-page todo-list webapp without the 300 supporting javascript libraries? So npm came to the rescue! People saw how shitty the dependency hell that RPM was and said, "How can we make this worse in every possible way?" And the last terrible horse of the apocalypse was born. Now all the pieces were there for people that don't know what they are doing to do those things on a large scale, with nothing remotely close to a reasonable development/debugging environment, and inject themselves as dependencies everywhere in the matrix. And then, of course, capriciously abandon the idea a week later. So rather than list all the valid criticism of the ways Javascript is being abused, just ask yourself "If I should use the right tool for the job, when is Javascript it?" I will tell you now that if "the job" is web-server, database, command line tool, yet another web-application framework (maybe), anything that needs reasonable or reliable error and failure handling, anything that looks like or acts like an desktop app, or anything that doesn't look or act like an desktop app (except for visitor counters and animated menus), or anything that any living human will ever have to support or debug ... then the answer is no.
- piano 9y ago
  One drawback of Node.js is that it's single threaded. Moreover, even if somehow it became multithreaded today, JS is absolutely not ready for that. (Btw. yes, async I/O is nice, but threads are useful for more than just I/O.) NPM is quite basic, it pretty much just downloads tarballs recursively from a webserver according to some version spec. The CommonJS module format is fairly loose (and kind of outlived its usefulnes) and so there's no agreed upon package structure and everyone just does whatever they feel like doing, which leads to a huge overall mess. The whole ecosystem is fragmented and very few things are really agreed-upon.
  - krainboltgreene 9y ago
    > NPM is quite basic, it pretty much just downloads tarballs recursively from a webserver according to some version spec This is about as valuable as "Rails is a webserver that responds to some HTTP verbs". Common.js isn't even a part of npm (the correct capitalization) or node.
    - piano 9y ago
      > Common.js isn't even a part of npm (the correct capitalization) or node. I never said it was, it's not part of it per se, but it's the 'blessed' module/package system on Node.js (the correct capitalization). Which is really sad, because CommonJS is retarded (a file has to actually be executed in order to get it's require & export characteristics and they might arbitrarily change in runtime). It's sad that Node.js as well as the JS ecosystem in general is fairly hostile towards ES6 modules - basically any current support of ES6 modules is just translating then / dumbing them down back to CJS. Hopefully this'll change in the future as ES6 gets more adopted and CommonJS will be left to rot (a fate it deserves and should've already met ages ago).
- patchguard 9y ago
  A mature framework should not have this kind of problems https://github.com/nodejs/node/issues/12115 https://github.com/nodejs/node/issues/12115
mcphage 9y ago
> I think it is ok to express displeasure at the state of something without just silently doing something else and hoping that the entire ecosystem catches up to you. It is, but it's not okay to bring up a common flame war topic and then say "but I don't want to start a flame war". If you don't want to start one, just don't start one. Starting it, and then saying you didn't want to, is disingenuous at best.
- bunderbunder 9y ago
  It's a legitimate thing to mention as being displeased about. The very fact that it's such a hot topic demonstrates that, since it indicates that it's a subject over which smart people can disagree. The "I don't want to start a flamewar" bit is also a reasonable addendum. It's a terse way of saying, "I don't like this feature, but, people who disagree with me, please don't get up in arms about this, you're free to like this feature if you want." Frankly, if there's anyone trying to start a flamewar, it's not the original poster; it's people who are edging toward caping up in response to OP's (quite mild) comment.

sillysaurus3 9y ago

Ok, so what are some legit criticisms of node.js and npm? I'm no fanboy, but every time I try to ask this, the answers are along the lines of "if you install packages in a different order, you get different results." Which is fair, but everybody installs using `npm i`, so that's mostly a moot point. Is there any substance here? I think it's fair to talk about this, as long as we go out of our way not to reduce it to flamewar territory. The app is built on Electron, after all. Maybe avoid mentioning memory usage, since that point has been done to death.

Jach 9y ago
What counts as a legit criticism? So much of our field is taste-driven. And so much criticism was aimed at old iterations of something, gets carried on in flamewars, but no longer applies to the latest version (e.g. "Java is slow"). All the JS-the-language criticisms apply, those are probably the biggest at this point. The classic "node.js is cancer" is still somewhat relevant though I never thought it made its point well enough on how forced-asynchronous is at least as bad as the forced OOP and checked exceptions we put up with in e.g. Java again. Callback hell was long a common complaint, until people found Promises / the waterfall structure, but then the complaint is debugging hell. The new await stuff in node 8 sounds nice at least. For a long time npm didn't get stuff over https by default, I think it does for a year now? The only other criticisms I can think of are just shoddy engineering that turns into drama (I remember seeing something about their colorized output would slow everything down quite a lot) or more taste-level things like how seemingly trivial concepts like leftpad are core libraries (that go through multiple versions because it couldn't have just been done right the first time) and the drama involved when something everyone depends on has an issue. Disclaimer, I haven't done production node since ~2013. It was actually mostly enjoyable, and I wouldn't mind doing it again, despite on the taste-level I think the whole node ecosystem is just worse than many other options (when you have a choice) for many specific problems. But life is a continuous lesson in Worse is Better.
mhuffman 9y ago
> Ok, so what are some legit criticisms of node.js and npm? I am glad you asked! You know how everyone runs to circle-jerk the praise "use the right tool for the job"? Well, Javascript is NEVER the right answer when the "job" is business logic or systems development or almost anything else. But here we are. Do you know why people think Javascript is fucking cancer? Because it was developed to animate visitor counters and help with animated menu and resize issues that css wasn't up to at the time. It doesn't have strong types and rigid structure because it was created to be a language that assists your browser in little ways. So a little more history is in order. Along comes Microsoft and creates XMLHttpRequest which could offer a "real-time" feel to some websites, and it was awesome! This was the first horseman of the apocalypse. Then Google blew everyone's fucking minds with google maps (inc. google earth) and gmail. And was basically single-handedly responsible for the Web 2.0 (single-page app) explosion...and the second horse of the apocalypse. Javascript grew and metastasized in every way imaginable, because everyone felt that single-page apps were exactly what they needed for their new toilet-sharing app idea, and so it went. Then one dark day Node.js emerged from is leathery egg and blew everyone's fucking mind again with what could be done when you get a genius to abuse the javascript engine for entertainment. And the worst pale horse of the apocalypse rode forth. For, you see, now webpage developers who know two days worth of shitty Javascript could now call themselves "full-stack developers". And oh my fucking god did they develop! Every afterbirth of an idea was haphazardly put together into a short script and posted to blow everyones fucking minds with how awesome their new 1,000-line sentence capitalization script was. Now with this torrent of javascript libraries from all the new developers that didn't know they were developers but totally were, came a problem. How could we get all of the diarrhea into everyone's mouths as efficiently as possible? I mean how are you going to write your single-page todo-list webapp without the 300 supporting javascript libraries? So npm came to the rescue! People saw how shitty the dependency hell that RPM was and said, "How can we make this worse in every possible way?" And the last terrible horse of the apocalypse was born. Now all the pieces were there for people that don't know what they are doing to do those things on a large scale, with nothing remotely close to a reasonable development/debugging environment, and inject themselves as dependencies everywhere in the matrix. And then, of course, capriciously abandon the idea a week later. So rather than list all the valid criticism of the ways Javascript is being abused, just ask yourself "If I should use the right tool for the job, when is Javascript it?" I will tell you now that if "the job" is web-server, database, command line tool, yet another web-application framework (maybe), anything that needs reasonable or reliable error and failure handling, anything that looks like or acts like an desktop app, or anything that doesn't look or act like an desktop app (except for visitor counters and animated menus), or anything that any living human will ever have to support or debug ... then the answer is no.
piano 9y ago
One drawback of Node.js is that it's single threaded. Moreover, even if somehow it became multithreaded today, JS is absolutely not ready for that. (Btw. yes, async I/O is nice, but threads are useful for more than just I/O.) NPM is quite basic, it pretty much just downloads tarballs recursively from a webserver according to some version spec. The CommonJS module format is fairly loose (and kind of outlived its usefulnes) and so there's no agreed upon package structure and everyone just does whatever they feel like doing, which leads to a huge overall mess. The whole ecosystem is fragmented and very few things are really agreed-upon.
- krainboltgreene 9y ago
  > NPM is quite basic, it pretty much just downloads tarballs recursively from a webserver according to some version spec This is about as valuable as "Rails is a webserver that responds to some HTTP verbs". Common.js isn't even a part of npm (the correct capitalization) or node.
  - piano 9y ago
    > Common.js isn't even a part of npm (the correct capitalization) or node. I never said it was, it's not part of it per se, but it's the 'blessed' module/package system on Node.js (the correct capitalization). Which is really sad, because CommonJS is retarded (a file has to actually be executed in order to get it's require & export characteristics and they might arbitrarily change in runtime). It's sad that Node.js as well as the JS ecosystem in general is fairly hostile towards ES6 modules - basically any current support of ES6 modules is just translating then / dumbing them down back to CJS. Hopefully this'll change in the future as ES6 gets more adopted and CommonJS will be left to rot (a fate it deserves and should've already met ages ago).
patchguard 9y ago
A mature framework should not have this kind of problems https://github.com/nodejs/node/issues/12115 https://github.com/nodejs/node/issues/12115

mcphage 9y ago

> I think it is ok to express displeasure at the state of something without just silently doing something else and hoping that the entire ecosystem catches up to you. It is, but it's not okay to bring up a common flame war topic and then say "but I don't want to start a flame war". If you don't want to start one, just don't start one. Starting it, and then saying you didn't want to, is disingenuous at best.

bunderbunder 9y ago
It's a legitimate thing to mention as being displeased about. The very fact that it's such a hot topic demonstrates that, since it indicates that it's a subject over which smart people can disagree. The "I don't want to start a flamewar" bit is also a reasonable addendum. It's a terse way of saying, "I don't like this feature, but, people who disagree with me, please don't get up in arms about this, you're free to like this feature if you want." Frankly, if there's anyone trying to start a flamewar, it's not the original poster; it's people who are edging toward caping up in response to OP's (quite mild) comment.