11 ms·

Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to

Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. How stupid of people to reuse small often used functions that only do one thing well. How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip? It's not javascript devs fault that the standard library is so piss poor you need these short code snippets and I've definitely included small 5-10 line packages via npm or other package managers rather than roll my own because it's likely they have bug fixes I haven't considered. I can also use npm to share these snippets between the many projects I'm building. * No I wasn't affected by this because I review the packages that I want to include, however the level of smugness here is absolutely ridiculous.

eknkc 11y ago
I use a lot of micro modules. And I think micro modules are a good idea. But this whole thing is freaking funny. You gotta acknowledge that.
- andy_ppp 11y ago
  I dunno; I think it's a balancing act between dependencies and code reuse. I think npm needs to not let people unpublish stuff without thought - that is where the problem is and I'm sure they are thinking about a solution to this. I think a lot of this is implying "don't use micro packages on your package manager, copy and paste code in helpers.js FTW". I've seen people advocating this as if it's a better solution than have npm remain consistent even after people unpublish packages.
  - eknkc 11y ago
    Well, I don't think we can trust NPM on being consistent. They gave away this guy's package to a corp, despite his protest just because they felt like it. I'm not arguing if it was the correct decision or not, it's just an arbitrary decision based on isaac's mood that day. It's best to treat NPM as mutable and don't depend on it. For example, I check in node_modules to git, even though everyone says no, use shrinkwrap! Yeah, that would definately help here. NPM is to blame here and people are right to make fun of the entire ecosystem around it. Also, It's just easy and funny. Noone will start copying stuff around just because of this I believe. The micromodule ecosystem emerged because it works for people apparently. Devs will find ways to make it work better.
    - btilly 11y ago
      Not exactly, "just because they felt like it." But rather because they didn't wish to lawyer up for a trademark dispute that they had no particular reason to want to be involved in. (One where there was a reasonable chance that they would lose.)
  - askyourmother 11y ago
    You think the only thing about the whole situation that is a problem is that npm let an author unpublish, rather than all the projects came to depend on so many external functions, sorry got to get the npm terminology the right, "modules"?
  - deong 11y ago
    What's that, you say? I can't "unpublish" my own code? Fine then, here you go. $ echo "function leftpad(str, len, ch) { return ""; }" > leftpad.js $ git commit -a -m "fuck you" && git push There is (obviously, I would say) no possible solution to the problem of the maintainer of a module you depend on deciding to mess with you. The only serious way to even make a go of it is to move your repository to a curated model where you (in this case, the NPM owners themselves) personally vet all contributions before allowing them in, and even then, I'm confident I can slip something into my own code that will cause problems if I want to -- it's code that I wrote and I've maintained for years and that you've looked at briefly every once in a while.
    - icebraining 11y ago
      That wouldn't mess with me. It would just create a new version, while my dependencies tracking file is locked to the previous one. I only fetch new versions to my local development machine, and only update the dependencies file after testing it locally and on the staging server.
      - Anchor 11y ago
        How about adding a line that alters the output randomly every 1000th second. Is your UI testing strategy good enough to pick that up? Or do you code review all your dependencies on version changes? I was bitten by a JS function change in a package that has been named also in this thread. It was an "oh, we moved that functionality to a new function, but reused the old name for a new function that does nothing like the old". And no semantic versioning. Slipped through UI testing and broke production functionality. I did not like dependencies before, and I like them even less now. And people keep wondering why everyone's software is so ridiculously bad.
    - rdancer 11y ago
      Yes, but you're jumping in the middle of it. A sane package repository won't disappear overnight, or ever. I can still install packages distributed with Debian Potato, the first ever Linux distro I used, which is now 15 years old. The code that I wrote against the libraries distributed with it will still compile, and had I only burnt stripped binaries to a CD back then, they would still runtime-link and run today on a brand-new install. And because it is all free software, the people and orgs who wrote those libraries, compiler, and standards, had given up their rights to force unpublication. In a sane package management system, and with version pinning on the consumer's side, your hissy fit would have had exactly zero effect. Assuming your package were free software, people could fork it, and still make improvements.
afandian 11y ago
I think it's less smugness (there certainly is some) and more disbelief / unfamiliarity. JS isn't the first language without great libraries (C's stdlib, `math.h`, `string.h` are good but don't have string padding functions, for example) so there's precedence going back a very long way. Most solutions involve coming up with a utilities library that contains the basic things (like a math library, or a strings library). There's nothing wrong with creating utility libraries for JS. I think people are surprised because the approach taken - that they are composable down to the function - is so radically different from the industry standard. Coupled with a package manager that requires fetching so many deps for such trivial functionality. People do tend to form isolated communities around languages (look at the language for basic data structures between PHP, Ruby and Python) and this kind of thing probably helps shake up that isolation which is probably good for both sides. (I could be wrong it could just be sneering)
- swalberg 11y ago
  sprintf and friends will pad strings for you, no? printf("%20s\n", "Hello");
- creshal 11y ago
  Even the Java ecosystem managed to get their crap together and make the excellent Apache Commons library collection to deal with a similar situation (anaemic to useless standard library). C++ has STL and Boost. Only the PHP and JS communities seem to think that not having a solidly designed "base" library is fine (and even PHP seems to be getting better at it with 7).
  - morsch 11y ago
    The Java standard library is anemic? As in Java SE? That's rich. Java SE is an everything but the kitchen sink standard library, with functionality like collection classes, local and networking IO, windowing toolkits (more than one), database connectivity, the list goes on. There is no language with a less anemic standard library, and Java SE is often criticized for being too large.
    - 11y ago
mdpopescu 11y ago
Thank you. I thought I was the only one who thought the whole thing sounded like a smug "look, there are worse programmers than me out there". Even more annoying, IMO, is the fact that this was a freaking denial-of-service over thousands of projects which was solved IN HOURS. Instead of celebrating the resilience of the duct-taped Jenga game that is the internet, we're complaining about how other programmers should be more like ourselves? What is this, vi vs emacs? :D
RVuRnvbM2e 11y ago
> How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. Obviously people shouldn't have trusted npm - that's the reason things broke in the first place! > How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip? The usual method is to bundle dependencies rather than pull them down from the web at deploy-time. That or use a package manager with rather stronger guarantees on availability of packages. > It's not javascript devs fault that the standard library is so piss poor you need these short code snippets This is very true. > the level of smugness here is absolutely ridiculous. Also true, but funny nonetheless.
roddux 11y ago
>How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip? By signing packages and not allowing literally anybody to re-upload a brand new package that does something completely different under the name of an existing, widely-used package. There's not much excuse for that in any respectable package manager.
- andy_ppp 11y ago
  Okay so have you checked all of the apt repos you've added to sources over the years or has one of the ppa's changed to something malicious?
  - roddux 11y ago
    I use Arch and only official sources, that are checked over and signed by a small well-trusted team[1]. Nothing like npm's model. [1]: https://www.archlinux.org/master-keys/ https://www.archlinux.org/master-keys/
  - zeveb 11y ago
    I've added exactly 0 apt sources, precisely because relying on ppas and the like is terribly, terribly insecure. Allow some random person to run code on my machine as root — that's insane.
mhd 11y ago
I'm with Knuth here, a lot of the arguments for discrete function units sound like premature optimization. In the end, you won't get the equivalent of the MODULA-3 standard library or something equally well-defined, but PHP4's mudball of functions. All this because a few bytes of functions would ruin your experience and/or dead code eliminiation isn't part of your pipeline.
amatheus 11y ago
Well, Jane Street found Ocaml's standard library lacking and went on to build a better one. To me it seems much better than build a "standard library" piece-by-piece from one-function packages.
- orf 11y ago
  Isn't that kind of what Lodash is?
  - halostatue 11y ago
    My understanding is that Lodash started as a replacement for Underscore.js and was originally fairly monolithic. Only in the most recent version do they make it so that each function is separately requirable and published. They have modularized after starting monolithically (without verifying, I also think that Lodash develops in a single repository, but publishes a bunch of modules from that one repo).
  - xlm1717 11y ago
    It even includes a function for padding strings. I think you would be doing better for yourself using lodash over left-pad, and the cost of including a bigger library on server-side JS is negligible.
pdkl95 11y ago
> How stupid of people to reuse small often used functions that only do one thing well. This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. > trust their package manager That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen. The "stupid" part is pretending these have zero risk, and the part that makes some people angry is when they also have to depend on this zero-risk assumption transitively through another library. > It's not javascript devs fault that the standard library is so piss poor Nobody is claiming it was. However, Javascript devs are responsible when they add critical dependencies on external components. They are also responsible when they publish libraries that extend those critical dependencies to the people that use their library without a very good reason.
- naasking 11y ago
  > This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.
  - ksml 11y ago
    > The cost of a dependency for a good package manager is zero I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell
    - naasking 11y ago
      That's a good point that's not often considered. That sounds like it should be part of a package manager too, because all you need is a license compatibility matrix.
  - 11y ago
pgpkkg 11y ago
There are two main factors that you're ignoring: The first is that every added dependency creates ongoing cost, and that in a world where it becomes typical for a single application to have hundreds of dependencies, this cost is non-trivial and is, at minimum, worth considering. The second is that even before the left-pad fiasco, a lot of experienced individuals (myself included) believed that npm is fragile by design; and that the dependency situation means that if you want to avoid nasty surprises, you need to pin every version of every dependency and you need to keep your own local copies of all of the files in case something like this happens. Overall, you're accusing others of failing to fully understand the situation and of being condescending and rude; but you're doing it in a way that is condescending and rude, and that fails to fully understand the situation. Responses like yours are completely unhelpful. They do not change hearts or minds. They do not help npm fix their problems. And your caricature of those who find the situation funny is so distorted from reality that nobody will see themselves in it. The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand.
- andy_ppp 11y ago
  >>> a lot of experienced individuals (myself included) believed that npm is fragile by design I agree with you! >>> you're accusing others of failing to fully understand the situation and of being condescending and rude I'm saying that people who say "massive helpers.js file yo" is not a solution. Improve the standard lib, npm and use lodash. I'm also saying we all rely on other package managers so don't think just because you saw npm as flawed you get a free ride to say this couldn't happen with other systems. All of them have various ways of poking holes in any security you think they have. At some point you have to put trust in your package manager. I'm riling against the people saying to copy and paste code everywhere. >>> The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand. Disagree sure, but I think to say that my post is from a cesspool is a bit over the top!
askyourmother 11y ago
The laughter is mostly the same as in the crowd points out the "new clothes" actually aren't any clothes at all. The modern, funky, hip, js "devs" told us we didn't "understand" they are doing modularity, code reuse, all those good things. Then the larger crowd realised they are publishing gazillions "modules" each of which is barely a function, some of which have horrendous runtime performance despite their wide inclusion by the crack a-team of js "devs".
- sedeki 11y ago
  I don't know why this got downvoted. This is exactly spot on.
jasim 11y ago
Javascript has an excellent standard library - lodash. Here is its string padding: https://lodash.com/docs#pad https://lodash.com/docs#pad. Lodash also ships hundreds of independent npm modules for those who don't need the entire package. Here is pad as an independent package: https://www.npmjs.com/package/lodash.pad https://www.npmjs.com/package/lodash.pad. Lodash is here today, it works, it is reliable, and it doesn't pull the rug from under you.
- jasongill 11y ago
  Lodash only got padLeft in version 3.0.0 (released last January), and then that method was renamed to padStart in 4.0.0 this January, so it's not exactly the paragon of reliability (although I understand your sentiment)
  - sod 11y ago
    dalton likes to name methods as ecmascript itself, what I very much appreciate. padStart() was proposed as standard after lodash 3.0.0 was released. So he changed it on the next major release: https://github.com/tc39/proposal-string-pad-start-end https://github.com/tc39/proposal-string-pad-start-end
  - jdd 11y ago
    Naw, I changed it on a major bump which requires opt-in and didn't pull the rug out from underneath people. As @sod pointed out the change is based on the newish ES7 proposal.
- buster 11y ago
  That's not a standard library.
  - talideon 11y ago
    Sure, but one reasonably cohesive library is better than a whole mess of tiny ones.
    - 11y ago
return0 11y ago
I think you're taking it too seriously. This criticism is a good think for npm. Too much cheerleading inevitably leads to lower quality in most communities. I assume people are not going to quit using npm anyway (although I don't use it myself).
zeveb 11y ago
> It's not javascript devs fault that the standard library is so piss poor you need these short code snippet Well, they could use a better language which compiles to Javascript …
beeker87 11y ago
Wouldn't it be a lot easier and more secure if you simply looked up the code in these packages you're using, reviewed the code to make sure it's legitimate, then copied it to say, your own utils.js package? I'm not even talking about the left-pad package, which shouldn't even be part of the discussion... If you're worried about including 2-4 lines of code on your own then you shouldn't be making an application other people will use in the first place. Apparently it's not obvious that having a ton of dependencies on 3rd party packages, of which can change at any time on the whim of the owner, is pretty insane in terms of security and minimizing complexity of your application. You do realize that even though you reviewed the 20 different packages you use at one time, they can change at any time? I would love to hear what a senior dev at any reputable, long established technology company thinks about including tens, if not hundreds (and some apps, thousands?) of 3rd party packages from strangers on the internet with no validity checks in place. Sign me up!
- deleted 11y ago
  [deleted]
KirinDave 11y ago
> How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. Well... Maybe a better word is naive? Because every additional package dependency is a risk. It's a risk in a security sense (has anyone ever wondered what is in left-pad in your organization?) and an engineering sense, as demonstrated by the latest JavaScript Bro if the month's industry-crushing personal power fantasy that you all cheerfully turned into reality by letting him control trivial but critical parts of your codebase. It's true that to an extent, that risk is unavoidable if you want code reuse. Too little code sharing has the exact same problem! But I think that arguing that any programmer in a position to need left-pad should be given edit rights to a non-toy project is what were needling you all about. The node communtiy has gone too far in one direction and embraced reuse for reuse's sake, not to address any real complexity.
babo 11y ago
So you are refused to use react or babel, right?
kelvin0 11y ago
I'm impressed how fast someone was able to turn this into a Unicorn :-) VCs will be stepping all over each other over this! Seriously, some languages have broken package systems and it looks like it's not the case for JS ... in fact it's working so well they are used ad nauseam, for trivial things even. This is to be expected from a language that is very flexible, but does not offer 'standard' ways of doing things built in, or at least offers the functionality as part of the distribution of the language libs/modules. JS just hit puberty, and will mature ...
coldtea 11y ago
>Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. How stupid of people to reuse small often used functions that only do one thing well. I don't get the supposed irony. Beyond a certain level it is indeed stupid of them. And the examples we've seen were all below that level.
cookiecaper 11y ago
>It's not javascript devs fault that the standard library is so piss poor you need these short code snippets and I've definitely included small 5-10 line packages via npm or other package managers rather than roll my own because it's likely they have bug fixes I haven't considered. Correct, it's the fault of the devs who prioritize their ego and feeling trendy over the practicalities of software design. JavaScript is not a good platform for Real Work(TM). The fact that the stdlib is tiny and such basic functions have to be imported from some random guy's library is a testament to this fact. Personally I can't wait for the JS-everywhere fad to die out.
smhg 11y ago
Yes, it's a smug joke, but I think it's a funny joke nonetheless (if you got the context). Don't take it too serious. So many good things happen in the JavaScript ecosystem. Nothing is perfect. This kind of criticism can help. Even if it's a bit much these days/hours ;) I can't imagine npm and many others won't learn something from this. What more can you ask for?
andy_ppp 11y ago
This [1], discussed in another thread is an incredible summary of the issues; I hadn't even thought about packages that are required by other packages; it can lead to literally thousands of deps :-o. Node/npm and the web need a standard library that can be included piecemeal, from a well trusted source and packages that only depend upon this small subset should be highlighted. require('std/string/pad'); [1] http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/ http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/
guelo 11y ago
In most other languages you end up with a poor approximation of npm's micro-libraries via stackoverflow copy-paste. Actually thinking about it, an ideal solution would be a combination of stackoverflow and npm: all the solutions to a problem grouped together in one place with community votes and comments, and then you can subscribe to an answer from your code.
- d0m 11y ago
  This is what npm/github is! Rather than having comments in one thread you have them spread in issues and pull request.
krinchan 11y ago
I think it's more that people writing libraries are depending on left-pad. You can write the function in almost the time it takes to add and install the dependency. Furthermore, left-pad didn't really do one thing well. It did one specific subcase of one specific problem well. That's like a tenth of a thing, for a definition of well that basically means "written by a monkey taking an npm tutorial". This also feeds into an extreme example of the continuing discussion around the cost/value/risks of extensive, transitive dependencies with the general consensus being that you would've been better off writing your own left-pad function 1,000 times rather than forcing the risk of this dependency onto your downstream.
darkarmani 11y ago
> isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! Exactly. And no amount of evidence or disasters will ever convince them otherwise, so we all laugh at them.

eknkc 11y ago

I use a lot of micro modules. And I think micro modules are a good idea. But this whole thing is freaking funny. You gotta acknowledge that.

andy_ppp 11y ago
I dunno; I think it's a balancing act between dependencies and code reuse. I think npm needs to not let people unpublish stuff without thought - that is where the problem is and I'm sure they are thinking about a solution to this. I think a lot of this is implying "don't use micro packages on your package manager, copy and paste code in helpers.js FTW". I've seen people advocating this as if it's a better solution than have npm remain consistent even after people unpublish packages.
- eknkc 11y ago
  Well, I don't think we can trust NPM on being consistent. They gave away this guy's package to a corp, despite his protest just because they felt like it. I'm not arguing if it was the correct decision or not, it's just an arbitrary decision based on isaac's mood that day. It's best to treat NPM as mutable and don't depend on it. For example, I check in node_modules to git, even though everyone says no, use shrinkwrap! Yeah, that would definately help here. NPM is to blame here and people are right to make fun of the entire ecosystem around it. Also, It's just easy and funny. Noone will start copying stuff around just because of this I believe. The micromodule ecosystem emerged because it works for people apparently. Devs will find ways to make it work better.
  - btilly 11y ago
    Not exactly, "just because they felt like it." But rather because they didn't wish to lawyer up for a trademark dispute that they had no particular reason to want to be involved in. (One where there was a reasonable chance that they would lose.)
- askyourmother 11y ago
  You think the only thing about the whole situation that is a problem is that npm let an author unpublish, rather than all the projects came to depend on so many external functions, sorry got to get the npm terminology the right, "modules"?
- deong 11y ago
  What's that, you say? I can't "unpublish" my own code? Fine then, here you go. $ echo "function leftpad(str, len, ch) { return ""; }" > leftpad.js $ git commit -a -m "fuck you" && git push There is (obviously, I would say) no possible solution to the problem of the maintainer of a module you depend on deciding to mess with you. The only serious way to even make a go of it is to move your repository to a curated model where you (in this case, the NPM owners themselves) personally vet all contributions before allowing them in, and even then, I'm confident I can slip something into my own code that will cause problems if I want to -- it's code that I wrote and I've maintained for years and that you've looked at briefly every once in a while.
  - icebraining 11y ago
    That wouldn't mess with me. It would just create a new version, while my dependencies tracking file is locked to the previous one. I only fetch new versions to my local development machine, and only update the dependencies file after testing it locally and on the staging server.
    - Anchor 11y ago
      How about adding a line that alters the output randomly every 1000th second. Is your UI testing strategy good enough to pick that up? Or do you code review all your dependencies on version changes? I was bitten by a JS function change in a package that has been named also in this thread. It was an "oh, we moved that functionality to a new function, but reused the old name for a new function that does nothing like the old". And no semantic versioning. Slipped through UI testing and broke production functionality. I did not like dependencies before, and I like them even less now. And people keep wondering why everyone's software is so ridiculously bad.
  - rdancer 11y ago
    Yes, but you're jumping in the middle of it. A sane package repository won't disappear overnight, or ever. I can still install packages distributed with Debian Potato, the first ever Linux distro I used, which is now 15 years old. The code that I wrote against the libraries distributed with it will still compile, and had I only burnt stripped binaries to a CD back then, they would still runtime-link and run today on a brand-new install. And because it is all free software, the people and orgs who wrote those libraries, compiler, and standards, had given up their rights to force unpublication. In a sane package management system, and with version pinning on the consumer's side, your hissy fit would have had exactly zero effect. Assuming your package were free software, people could fork it, and still make improvements.

afandian 11y ago

I think it's less smugness (there certainly is some) and more disbelief / unfamiliarity. JS isn't the first language without great libraries (C's stdlib, `math.h`, `string.h` are good but don't have string padding functions, for example) so there's precedence going back a very long way. Most solutions involve coming up with a utilities library that contains the basic things (like a math library, or a strings library). There's nothing wrong with creating utility libraries for JS. I think people are surprised because the approach taken - that they are composable down to the function - is so radically different from the industry standard. Coupled with a package manager that requires fetching so many deps for such trivial functionality. People do tend to form isolated communities around languages (look at the language for basic data structures between PHP, Ruby and Python) and this kind of thing probably helps shake up that isolation which is probably good for both sides. (I could be wrong it could just be sneering)

swalberg 11y ago
sprintf and friends will pad strings for you, no? printf("%20s\n", "Hello");
creshal 11y ago
Even the Java ecosystem managed to get their crap together and make the excellent Apache Commons library collection to deal with a similar situation (anaemic to useless standard library). C++ has STL and Boost. Only the PHP and JS communities seem to think that not having a solidly designed "base" library is fine (and even PHP seems to be getting better at it with 7).
- morsch 11y ago
  The Java standard library is anemic? As in Java SE? That's rich. Java SE is an everything but the kitchen sink standard library, with functionality like collection classes, local and networking IO, windowing toolkits (more than one), database connectivity, the list goes on. There is no language with a less anemic standard library, and Java SE is often criticized for being too large.
  - 11y ago

mdpopescu 11y ago

Thank you. I thought I was the only one who thought the whole thing sounded like a smug "look, there are worse programmers than me out there". Even more annoying, IMO, is the fact that this was a freaking denial-of-service over thousands of projects which was solved IN HOURS. Instead of celebrating the resilience of the duct-taped Jenga game that is the internet, we're complaining about how other programmers should be more like ourselves? What is this, vi vs emacs? :D

RVuRnvbM2e 11y ago

> How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. Obviously people shouldn't have trusted npm - that's the reason things broke in the first place! > How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip? The usual method is to bundle dependencies rather than pull them down from the web at deploy-time. That or use a package manager with rather stronger guarantees on availability of packages. > It's not javascript devs fault that the standard library is so piss poor you need these short code snippets This is very true. > the level of smugness here is absolutely ridiculous. Also true, but funny nonetheless.

roddux 11y ago

>How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip? By signing packages and not allowing literally anybody to re-upload a brand new package that does something completely different under the name of an existing, widely-used package. There's not much excuse for that in any respectable package manager.

andy_ppp 11y ago
Okay so have you checked all of the apt repos you've added to sources over the years or has one of the ppa's changed to something malicious?
- roddux 11y ago
  I use Arch and only official sources, that are checked over and signed by a small well-trusted team[1]. Nothing like npm's model. [1]: https://www.archlinux.org/master-keys/ https://www.archlinux.org/master-keys/
- zeveb 11y ago
  I've added exactly 0 apt sources, precisely because relying on ppas and the like is terribly, terribly insecure. Allow some random person to run code on my machine as root — that's insane.

mhd 11y ago

I'm with Knuth here, a lot of the arguments for discrete function units sound like premature optimization. In the end, you won't get the equivalent of the MODULA-3 standard library or something equally well-defined, but PHP4's mudball of functions. All this because a few bytes of functions would ruin your experience and/or dead code eliminiation isn't part of your pipeline.

amatheus 11y ago

Well, Jane Street found Ocaml's standard library lacking and went on to build a better one. To me it seems much better than build a "standard library" piece-by-piece from one-function packages.

orf 11y ago
Isn't that kind of what Lodash is?
- halostatue 11y ago
  My understanding is that Lodash started as a replacement for Underscore.js and was originally fairly monolithic. Only in the most recent version do they make it so that each function is separately requirable and published. They have modularized after starting monolithically (without verifying, I also think that Lodash develops in a single repository, but publishes a bunch of modules from that one repo).
- xlm1717 11y ago
  It even includes a function for padding strings. I think you would be doing better for yourself using lodash over left-pad, and the cost of including a bigger library on server-side JS is negligible.

pdkl95 11y ago

> How stupid of people to reuse small often used functions that only do one thing well. This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. > trust their package manager That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen. The "stupid" part is pretending these have zero risk, and the part that makes some people angry is when they also have to depend on this zero-risk assumption transitively through another library. > It's not javascript devs fault that the standard library is so piss poor Nobody is claiming it was. However, Javascript devs are responsible when they add critical dependencies on external components. They are also responsible when they publish libraries that extend those critical dependencies to the people that use their library without a very good reason.

naasking 11y ago
> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.
- ksml 11y ago
  > The cost of a dependency for a good package manager is zero I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell
  - naasking 11y ago
    That's a good point that's not often considered. That sounds like it should be part of a package manager too, because all you need is a license compatibility matrix.
- 11y ago

pgpkkg 11y ago

There are two main factors that you're ignoring: The first is that every added dependency creates ongoing cost, and that in a world where it becomes typical for a single application to have hundreds of dependencies, this cost is non-trivial and is, at minimum, worth considering. The second is that even before the left-pad fiasco, a lot of experienced individuals (myself included) believed that npm is fragile by design; and that the dependency situation means that if you want to avoid nasty surprises, you need to pin every version of every dependency and you need to keep your own local copies of all of the files in case something like this happens. Overall, you're accusing others of failing to fully understand the situation and of being condescending and rude; but you're doing it in a way that is condescending and rude, and that fails to fully understand the situation. Responses like yours are completely unhelpful. They do not change hearts or minds. They do not help npm fix their problems. And your caricature of those who find the situation funny is so distorted from reality that nobody will see themselves in it. The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand.

andy_ppp 11y ago
>>> a lot of experienced individuals (myself included) believed that npm is fragile by design I agree with you! >>> you're accusing others of failing to fully understand the situation and of being condescending and rude I'm saying that people who say "massive helpers.js file yo" is not a solution. Improve the standard lib, npm and use lodash. I'm also saying we all rely on other package managers so don't think just because you saw npm as flawed you get a free ride to say this couldn't happen with other systems. All of them have various ways of poking holes in any security you think they have. At some point you have to put trust in your package manager. I'm riling against the people saying to copy and paste code everywhere. >>> The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand. Disagree sure, but I think to say that my post is from a cesspool is a bit over the top!

askyourmother 11y ago

The laughter is mostly the same as in the crowd points out the "new clothes" actually aren't any clothes at all. The modern, funky, hip, js "devs" told us we didn't "understand" they are doing modularity, code reuse, all those good things. Then the larger crowd realised they are publishing gazillions "modules" each of which is barely a function, some of which have horrendous runtime performance despite their wide inclusion by the crack a-team of js "devs".

sedeki 11y ago
I don't know why this got downvoted. This is exactly spot on.

jasim 11y ago

Javascript has an excellent standard library - lodash. Here is its string padding: https://lodash.com/docs#pad https://lodash.com/docs#pad. Lodash also ships hundreds of independent npm modules for those who don't need the entire package. Here is pad as an independent package: https://www.npmjs.com/package/lodash.pad https://www.npmjs.com/package/lodash.pad. Lodash is here today, it works, it is reliable, and it doesn't pull the rug from under you.

jasongill 11y ago
Lodash only got padLeft in version 3.0.0 (released last January), and then that method was renamed to padStart in 4.0.0 this January, so it's not exactly the paragon of reliability (although I understand your sentiment)
- sod 11y ago
  dalton likes to name methods as ecmascript itself, what I very much appreciate. padStart() was proposed as standard after lodash 3.0.0 was released. So he changed it on the next major release: https://github.com/tc39/proposal-string-pad-start-end https://github.com/tc39/proposal-string-pad-start-end
- jdd 11y ago
  Naw, I changed it on a major bump which requires opt-in and didn't pull the rug out from underneath people. As @sod pointed out the change is based on the newish ES7 proposal.
buster 11y ago
That's not a standard library.
- talideon 11y ago
  Sure, but one reasonably cohesive library is better than a whole mess of tiny ones.
  - 11y ago

return0 11y ago

I think you're taking it too seriously. This criticism is a good think for npm. Too much cheerleading inevitably leads to lower quality in most communities. I assume people are not going to quit using npm anyway (although I don't use it myself).

zeveb 11y ago

> It's not javascript devs fault that the standard library is so piss poor you need these short code snippet Well, they could use a better language which compiles to Javascript …

beeker87 11y ago

Wouldn't it be a lot easier and more secure if you simply looked up the code in these packages you're using, reviewed the code to make sure it's legitimate, then copied it to say, your own utils.js package? I'm not even talking about the left-pad package, which shouldn't even be part of the discussion... If you're worried about including 2-4 lines of code on your own then you shouldn't be making an application other people will use in the first place. Apparently it's not obvious that having a ton of dependencies on 3rd party packages, of which can change at any time on the whim of the owner, is pretty insane in terms of security and minimizing complexity of your application. You do realize that even though you reviewed the 20 different packages you use at one time, they can change at any time? I would love to hear what a senior dev at any reputable, long established technology company thinks about including tens, if not hundreds (and some apps, thousands?) of 3rd party packages from strangers on the internet with no validity checks in place. Sign me up!

deleted 11y ago
[deleted]

KirinDave 11y ago

> How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. Well... Maybe a better word is naive? Because every additional package dependency is a risk. It's a risk in a security sense (has anyone ever wondered what is in left-pad in your organization?) and an engineering sense, as demonstrated by the latest JavaScript Bro if the month's industry-crushing personal power fantasy that you all cheerfully turned into reality by letting him control trivial but critical parts of your codebase. It's true that to an extent, that risk is unavoidable if you want code reuse. Too little code sharing has the exact same problem! But I think that arguing that any programmer in a position to need left-pad should be given edit rights to a non-toy project is what were needling you all about. The node communtiy has gone too far in one direction and embraced reuse for reuse's sake, not to address any real complexity.

babo 11y ago

So you are refused to use react or babel, right?

kelvin0 11y ago

I'm impressed how fast someone was able to turn this into a Unicorn :-) VCs will be stepping all over each other over this! Seriously, some languages have broken package systems and it looks like it's not the case for JS ... in fact it's working so well they are used ad nauseam, for trivial things even. This is to be expected from a language that is very flexible, but does not offer 'standard' ways of doing things built in, or at least offers the functionality as part of the distribution of the language libs/modules. JS just hit puberty, and will mature ...

coldtea 11y ago

>Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. How stupid of people to reuse small often used functions that only do one thing well. I don't get the supposed irony. Beyond a certain level it is indeed stupid of them. And the examples we've seen were all below that level.

cookiecaper 11y ago

>It's not javascript devs fault that the standard library is so piss poor you need these short code snippets and I've definitely included small 5-10 line packages via npm or other package managers rather than roll my own because it's likely they have bug fixes I haven't considered. Correct, it's the fault of the devs who prioritize their ego and feeling trendy over the practicalities of software design. JavaScript is not a good platform for Real Work(TM). The fact that the stdlib is tiny and such basic functions have to be imported from some random guy's library is a testament to this fact. Personally I can't wait for the JS-everywhere fad to die out.

smhg 11y ago

Yes, it's a smug joke, but I think it's a funny joke nonetheless (if you got the context). Don't take it too serious. So many good things happen in the JavaScript ecosystem. Nothing is perfect. This kind of criticism can help. Even if it's a bit much these days/hours ;) I can't imagine npm and many others won't learn something from this. What more can you ask for?

andy_ppp 11y ago

This [1], discussed in another thread is an incredible summary of the issues; I hadn't even thought about packages that are required by other packages; it can lead to literally thousands of deps :-o. Node/npm and the web need a standard library that can be included piecemeal, from a well trusted source and packages that only depend upon this small subset should be highlighted. require('std/string/pad'); [1] http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/ http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/

guelo 11y ago

In most other languages you end up with a poor approximation of npm's micro-libraries via stackoverflow copy-paste. Actually thinking about it, an ideal solution would be a combination of stackoverflow and npm: all the solutions to a problem grouped together in one place with community votes and comments, and then you can subscribe to an answer from your code.

d0m 11y ago
This is what npm/github is! Rather than having comments in one thread you have them spread in issues and pull request.

krinchan 11y ago

I think it's more that people writing libraries are depending on left-pad. You can write the function in almost the time it takes to add and install the dependency. Furthermore, left-pad didn't really do one thing well. It did one specific subcase of one specific problem well. That's like a tenth of a thing, for a definition of well that basically means "written by a monkey taking an npm tutorial". This also feeds into an extreme example of the continuing discussion around the cost/value/risks of extensive, transitive dependencies with the general consensus being that you would've been better off writing your own left-pad function 1,000 times rather than forcing the risk of this dependency onto your downstream.

darkarmani 11y ago

> isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! Exactly. And no amount of evidence or disasters will ever convince them otherwise, so we all laugh at them.