6 ms·

I'm not the author of the article, but could you expand on why it's click bait? Personally, I think NPM is a crazy, mental concept. As a Go developer (so mostl

by movedx 9y ago

I'm not the author of the article, but could you expand on why it's click bait? Personally, I think NPM is a crazy, mental concept. As a Go developer (so mostly server-side work) I can't fathom the amount of deps that are pulled from NPM when I'm working with or watching a JS code base being used. I assume server-side NodeJS code bases are the same their front end cousins in terms of deps pulled(?)

sbr464 9y ago
Hi, appreciate the followup, apologies for the previous short comment. I feel like it's clickbait, not worth reading, for these points: 1. Even if the argument is valid, the points made in this article have been expressed, shared, (whined about?) probably 9+ times in my own reading. It's really time to move on. 2. There is nothing inherently wrong with using small/simple modules. Once you start to reuse code in many projects, the value becomes clear. Some are juicy and complex, some are eye-bleeding simple. It's better than copying and pasting code around folders. Use org modules/private modules and the problem is solved. I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues. No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved. Jeez that reads harsh. Apologies, it's late.
- deleted 9y ago
  [deleted]
- zaarn 9y ago
  Not worth reading is different to clickbait. Clickbait is specifically a sensationalist headline that is above content with little to no actual journalistic value. The title of the post is a quite accurate summary of the entire text in a few words, so I think it totally serves it's purpose as a title. It matters little that the arguments have been brought up before, that only makes the article stale but not clickbait in of itself. Now, if there was a lack of an actual, journalistic article below the headline I might be more inclined to agree it being clickbait.
- movedx 9y ago
  > apologies for the previous short comment. > Jeez that reads harsh. Apologies, it's late. All good, friend. > ... It's really time to move on. But is it? I fear that if this is a genuine issue, why would I want to move on from it? Essentially npm is enabling people to build bridges in the same way steel is helping people to build actual bridges. If there was a flaw in some steel production process, I wouldn't ignore it. People could suffer. Extreme(?) examples a side, if it's an issue, why not aim to solve it? This seems to pop up a lot, so perhaps it's time for a (long-term) solution? > Use org modules/private modules and the problem is solved. Yes! This is where I personally see the long-term solution: pick your top-level deps, (permanently) cache them locally and validate them, then implement/use them. Only update the cache when you're confident the remote, official copy has been changed in a manner that's safe for you and or your users. > I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues. How do you know you've not had any issues? If I was attacking you via some sort of "side channel" attack, like breaching and injecting bad code into an NPM module I know you're using, how would you know it's happened? Are you using a CI/CD process? The changes are high that you are and therefore unless you've version/commit pinning, it's likely you're blind to those deps being updated during your build process, enabling me to perform said "side channel" attack. > No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved. If it's being regurgitated so much, perhaps it is a "real world" problem to be solved.
  - Can_Not 9y ago
    > If it's being regurgitated so much, perhaps it is a "real world" problem to be solved. I don't think most people deny that it's a problem or that it needs to be fixed. But completely blown out of proportion with Breitbart-esque fear-mongering is something that needs to stop. People still talk about "leftpad" as if it wasn't fixed the same day, sometimes as if it were never fixed, sometimes even as if it isn't even possible to write software in NodeJS. I haven't seen a fair and factual comparison chart of npm vs pip vs crate vs composer, and I'm calling BS that the majority of this "concern" is anything more than trendy JavaScript-Hate until I see one.
- pluma 9y ago
  Having written my fair share of tiny trivial modules, I think tree-shaking may actually help with the "everything's a package" craze that followed the early size concerns. Lodash and date-fns for example are similarly feature complete and "big" as underscore and moment.js but their structure allows using them as "a la carte" collections of tiny helper functions without bloating the frontend bundle. The fearmongering does get on your nerves but I think it's undeniable that npm's version conflict resolution (i.e. "have your cake and eat it too") has led to more complex dependency trees than e.g. in Python where the need to avoid version conflicts creates an inherent aversion to adding too many dependencies. However I think it's also undeniable that this has in turn enabled a lot of growth and innovation.
- caspervonb 9y ago
  > Breitbart-esque fearmongering WTH is Breitbart? Bart Simpsons's evil twin?
  - corrigible 9y ago
    Apparently it's an American alt-right news platform
royjacobs 9y ago
Isn't the way Go handles dependencies just as crazy? Not trying to troll here, but I don't think Go has an excellent track record in that area either.
- zaarn 9y ago
  I do a lot of go development and while it's not the most sane environment atm, there are solutions and the ecosystem makes it less of a problem. Breaking API compatibility is something that happens very rarely (I think I had to fix up applications of mine about once a year because some dependency changed), most packages with active development are very mature. Additionally we have tools like dep and (soon) vgo that allow you to vendor and pin certain dependencies at certain versions (you can do it manually too, /vendor/ is where go looks first for any dependencies so you can replicate "dep init" by copying all dependency paths in your gopath into /vendor/) There is also less "make a package for everything", packages tend to have much broader feature scope. is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package.
  - egeozcan 9y ago
    > is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package NPM does have an extra use case: Web development. Tree shaking in JS-land is still far from perfect and people don't want to (more like, are asked to) send as little as possible over the wire. So, different use cases, different trade-offs.
    - zaarn 9y ago
      Yes but go can do tree shaking and will not include packages in the binary that aren't used (that also means parent packages if a subpackage does not reference those). I'm mostly pointing out that despite vanilla go's complete lack of version pinning, the community has (had to necessarily) step up and solve this by engineering. Tree Shaking in JS should be trivial if the parent package implements no code and imports should be easy if they aren't of a dynamic nature (ie, "require('package/' + variable)") I'm not sure what is stopping NPM or Yarn from doing this atleast in the packaging step
politelemon 9y ago
I wouldn't say it's similar to front-end JS. With front-end dev you're dealing with programming logic as well as the chaotic world of browsers, DOMs, 'standards' (or the lack thereof) and other quirks which manifests itself in complex ways. Server side JS is more foucsed in what it does though you still get the dependency trees. Sure, you may consider npm crazy; consider what it's providing to the developer ecosystem. Conversely to your opinion, coming from C#, Java, Node... I would consider `go get` just as puzzling, as well as community members providing multiple package managers (with go dep only now being worked on). There are definitely good reasons for those no doubt, just as there are good reasons for npm's solution.
- movedx 9y ago
  I see npm has "crazy, mental" because of HOW it's used, not for its sheer existence as a "thing." Technically it's a good solution. Very solid. For me, it's more the mentality around just accepting a dependency tree made up of thousands of modules, with little to no validation or vetting, versus doing something to make sure what's being pulled is safe and even worth it. With a Go application, I would 'dep ensure' to vendor what I needed and then actually look at what was pulled. Once I know what's been brought down and I'm happy with the code, I "off line" (cache) those dependencies and never update them again unless I need to (security, bugs or big features.) Also now that they're vetted and off line, I can reuse them over and over in confidence. Thoughts?
wokwokwok 9y ago
> Don’t trust package managers, every dependency is written by some random developer somewhere in the world. How are we to take that seriously? Ever heard of not invented here syndrome? npm has problems, I won't deny it... but its not unique to javascript developers (which your comments about come off as extremely offensive), and its difficult to take seriously given the lack of any meaningful alternative offered. Its just a rant... and people love to hate on javascript... so... click bait. (also submitted what 3 times previously? And here I was hoping it would just wash away without triggering a js rant this time too..)
- movedx 9y ago
  > npm has problems, I won't deny it... but its not unique to javascript developers (which your comments about come off as extremely offensive), and its difficult to take seriously given the lack of any meaningful alternative offered. But it's not about npm as a technology, but about the mentality around how it's used. It enables laziness.
  - Can_Not 9y ago
    But people worship that laziness when it's not about JavaScript. E.g. the Unix philosophy.
askmike 9y ago
> As a Go developer Pardon my ignorance but last time I checked Go deps where a mess: you list deps as github repos always pointing to latest master. The concept of version control did not exist. I have written some go and write a lot of js. I'd choose npm over that everyday. > I assume server-side NodeJS code bases are the same their front end cousins in terms of deps pulled(?) Most frontend code bases use actually very little dependencies, the big blob of (dev) dependencies are in the build pipeline: you need to transpile, compile, optimize, bundle, etc. the codebase. You only need those if you want to compile the frontend. In order to run go code you need the compiler which is a binary of at least 100 megs. You can of course compile manually on your machine and push an executable, but you can do the same with a frontend (if your NODE_ENV is production npm will not download all compile deps).
- movedx 9y ago
  > last time I checked Go deps where a mess: you list deps as github repos always pointing to latest master Time to check again.
  - unicornode 9y ago
    Coming soon: vgo. Well it's out already but it's likely being rolled into Go in the next release.
dingo_bat 9y ago
> I think NPM is a crazy, mental concept > As a Go developer Pot, meet kettle.

by movedx 9y ago

sbr464 9y ago

Hi, appreciate the followup, apologies for the previous short comment. I feel like it's clickbait, not worth reading, for these points: 1. Even if the argument is valid, the points made in this article have been expressed, shared, (whined about?) probably 9+ times in my own reading. It's really time to move on. 2. There is nothing inherently wrong with using small/simple modules. Once you start to reuse code in many projects, the value becomes clear. Some are juicy and complex, some are eye-bleeding simple. It's better than copying and pasting code around folders. Use org modules/private modules and the problem is solved. I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues. No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved. Jeez that reads harsh. Apologies, it's late.

deleted 9y ago
[deleted]
zaarn 9y ago
Not worth reading is different to clickbait. Clickbait is specifically a sensationalist headline that is above content with little to no actual journalistic value. The title of the post is a quite accurate summary of the entire text in a few words, so I think it totally serves it's purpose as a title. It matters little that the arguments have been brought up before, that only makes the article stale but not clickbait in of itself. Now, if there was a lack of an actual, journalistic article below the headline I might be more inclined to agree it being clickbait.
movedx 9y ago
> apologies for the previous short comment. > Jeez that reads harsh. Apologies, it's late. All good, friend. > ... It's really time to move on. But is it? I fear that if this is a genuine issue, why would I want to move on from it? Essentially npm is enabling people to build bridges in the same way steel is helping people to build actual bridges. If there was a flaw in some steel production process, I wouldn't ignore it. People could suffer. Extreme(?) examples a side, if it's an issue, why not aim to solve it? This seems to pop up a lot, so perhaps it's time for a (long-term) solution? > Use org modules/private modules and the problem is solved. Yes! This is where I personally see the long-term solution: pick your top-level deps, (permanently) cache them locally and validate them, then implement/use them. Only update the cache when you're confident the remote, official copy has been changed in a manner that's safe for you and or your users. > I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues. How do you know you've not had any issues? If I was attacking you via some sort of "side channel" attack, like breaching and injecting bad code into an NPM module I know you're using, how would you know it's happened? Are you using a CI/CD process? The changes are high that you are and therefore unless you've version/commit pinning, it's likely you're blind to those deps being updated during your build process, enabling me to perform said "side channel" attack. > No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved. If it's being regurgitated so much, perhaps it is a "real world" problem to be solved.
- Can_Not 9y ago
  > If it's being regurgitated so much, perhaps it is a "real world" problem to be solved. I don't think most people deny that it's a problem or that it needs to be fixed. But completely blown out of proportion with Breitbart-esque fear-mongering is something that needs to stop. People still talk about "leftpad" as if it wasn't fixed the same day, sometimes as if it were never fixed, sometimes even as if it isn't even possible to write software in NodeJS. I haven't seen a fair and factual comparison chart of npm vs pip vs crate vs composer, and I'm calling BS that the majority of this "concern" is anything more than trendy JavaScript-Hate until I see one.
pluma 9y ago
Having written my fair share of tiny trivial modules, I think tree-shaking may actually help with the "everything's a package" craze that followed the early size concerns. Lodash and date-fns for example are similarly feature complete and "big" as underscore and moment.js but their structure allows using them as "a la carte" collections of tiny helper functions without bloating the frontend bundle. The fearmongering does get on your nerves but I think it's undeniable that npm's version conflict resolution (i.e. "have your cake and eat it too") has led to more complex dependency trees than e.g. in Python where the need to avoid version conflicts creates an inherent aversion to adding too many dependencies. However I think it's also undeniable that this has in turn enabled a lot of growth and innovation.
caspervonb 9y ago
> Breitbart-esque fearmongering WTH is Breitbart? Bart Simpsons's evil twin?
- corrigible 9y ago
  Apparently it's an American alt-right news platform

royjacobs 9y ago

Isn't the way Go handles dependencies just as crazy? Not trying to troll here, but I don't think Go has an excellent track record in that area either.

zaarn 9y ago
I do a lot of go development and while it's not the most sane environment atm, there are solutions and the ecosystem makes it less of a problem. Breaking API compatibility is something that happens very rarely (I think I had to fix up applications of mine about once a year because some dependency changed), most packages with active development are very mature. Additionally we have tools like dep and (soon) vgo that allow you to vendor and pin certain dependencies at certain versions (you can do it manually too, /vendor/ is where go looks first for any dependencies so you can replicate "dep init" by copying all dependency paths in your gopath into /vendor/) There is also less "make a package for everything", packages tend to have much broader feature scope. is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package.
- egeozcan 9y ago
  > is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package NPM does have an extra use case: Web development. Tree shaking in JS-land is still far from perfect and people don't want to (more like, are asked to) send as little as possible over the wire. So, different use cases, different trade-offs.
  - zaarn 9y ago
    Yes but go can do tree shaking and will not include packages in the binary that aren't used (that also means parent packages if a subpackage does not reference those). I'm mostly pointing out that despite vanilla go's complete lack of version pinning, the community has (had to necessarily) step up and solve this by engineering. Tree Shaking in JS should be trivial if the parent package implements no code and imports should be easy if they aren't of a dynamic nature (ie, "require('package/' + variable)") I'm not sure what is stopping NPM or Yarn from doing this atleast in the packaging step

politelemon 9y ago

I wouldn't say it's similar to front-end JS. With front-end dev you're dealing with programming logic as well as the chaotic world of browsers, DOMs, 'standards' (or the lack thereof) and other quirks which manifests itself in complex ways. Server side JS is more foucsed in what it does though you still get the dependency trees. Sure, you may consider npm crazy; consider what it's providing to the developer ecosystem. Conversely to your opinion, coming from C#, Java, Node... I would consider `go get` just as puzzling, as well as community members providing multiple package managers (with go dep only now being worked on). There are definitely good reasons for those no doubt, just as there are good reasons for npm's solution.

movedx 9y ago
I see npm has "crazy, mental" because of HOW it's used, not for its sheer existence as a "thing." Technically it's a good solution. Very solid. For me, it's more the mentality around just accepting a dependency tree made up of thousands of modules, with little to no validation or vetting, versus doing something to make sure what's being pulled is safe and even worth it. With a Go application, I would 'dep ensure' to vendor what I needed and then actually look at what was pulled. Once I know what's been brought down and I'm happy with the code, I "off line" (cache) those dependencies and never update them again unless I need to (security, bugs or big features.) Also now that they're vetted and off line, I can reuse them over and over in confidence. Thoughts?

wokwokwok 9y ago

> Don’t trust package managers, every dependency is written by some random developer somewhere in the world. How are we to take that seriously? Ever heard of not invented here syndrome? npm has problems, I won't deny it... but its not unique to javascript developers (which your comments about come off as extremely offensive), and its difficult to take seriously given the lack of any meaningful alternative offered. Its just a rant... and people love to hate on javascript... so... click bait. (also submitted what 3 times previously? And here I was hoping it would just wash away without triggering a js rant this time too..)

movedx 9y ago
> npm has problems, I won't deny it... but its not unique to javascript developers (which your comments about come off as extremely offensive), and its difficult to take seriously given the lack of any meaningful alternative offered. But it's not about npm as a technology, but about the mentality around how it's used. It enables laziness.
- Can_Not 9y ago
  But people worship that laziness when it's not about JavaScript. E.g. the Unix philosophy.

askmike 9y ago

> As a Go developer Pardon my ignorance but last time I checked Go deps where a mess: you list deps as github repos always pointing to latest master. The concept of version control did not exist. I have written some go and write a lot of js. I'd choose npm over that everyday. > I assume server-side NodeJS code bases are the same their front end cousins in terms of deps pulled(?) Most frontend code bases use actually very little dependencies, the big blob of (dev) dependencies are in the build pipeline: you need to transpile, compile, optimize, bundle, etc. the codebase. You only need those if you want to compile the frontend. In order to run go code you need the compiler which is a binary of at least 100 megs. You can of course compile manually on your machine and push an executable, but you can do the same with a frontend (if your NODE_ENV is production npm will not download all compile deps).

movedx 9y ago
> last time I checked Go deps where a mess: you list deps as github repos always pointing to latest master Time to check again.
- unicornode 9y ago
  Coming soon: vgo. Well it's out already but it's likely being rolled into Go in the next release.

dingo_bat 9y ago

> I think NPM is a crazy, mental concept > As a Go developer Pot, meet kettle.