6 ms·

I don't see anything wrong with using a pre-made left pad function. Why waste time and lines of code implementing something so trivial when there is already a s

I don't see anything wrong with using a pre-made left pad function. Why waste time and lines of code implementing something so trivial when there is already a solution available? However, I agree it is ridiculous to have a dedicated module for that one function. For most nontrivial projects I just include lodash, which contains tons and tons of handy utility functions that save time and provide efficient, fast implementations of solutions for common tasks. Lodash includes `padStart` by the way (https://lodash.com/docs#padStart https://lodash.com/docs#padStart).

zbuttram 11y ago
Some of the libraries people were mentioning broke yesterday already have lodash as dependencies, I have no idea why they wouldn't have just been using this...
- zbuttram 11y ago
  Someone mentioned below that lodash had some breaking changes related to the padding functions a couple times, which could be a totally valid reason to avoid using those. I was under the impression that the lodash API was more stable than to have that kind of thing happening.
  - jdd 11y ago
    Lodash renamed padding on a major version bump (which requires opting into) to better align with the ES7 proposal. Nothing was done in a way to pull the rug out from underneath folks.
fweespee_ch 11y ago
> However, I agree it is ridiculous to have a dedicated module for that one function. For most nontrivial projects I just include lodash, which contains tons and tons of handy utility functions that save time and provide efficient, fast implementations of solutions for common tasks. I think that was largely the OP's point tbh. Using something like lodash [a utility library] is fine while using a module [for a single function] is not. It might have gotten lost in the ranting from on high but I don't think the author truly meant more than that.
- Twirrim 11y ago
  For what it's worth, that's what I read in to it too.
chipotle_coyote 11y ago
I think the article's thesis is essentially that every dependency your project pulls in -- which includes all the dependencies your dependencies pull in -- is a point of potential failure. I understand the "don't re-invent the wheel" defense, but the Node/JavaScript ecosystem tacitly encourages its users to build vehicles by chaining together dozens of pre-made wheels, all of which depend on more wheels, and each and every one of those wheels has a small but non-zero chance of exploding the next time you type "npm update." (And, y'know, maybe it's because I'm not a JS programmer, but the notion of looking for a module to implement a string padding function would never have even occurred to me.)
- joantune 11y ago
  The problem is not that, the problem is depending on unreleased versions, instead of simply depending on the version that was written when u wrote your code. a Git submodule like approach would be much better
- nv-vn 11y ago
  Worse yet, a backdoor or legitimate bug in any of these module could leave huge exploits in the entire Node.js ecosystem.
  - smokeyj 11y ago
    Worse yet, the OS is compromised. This is why I hand roll all my encryption libraries. /s
    - cyphar 11y ago
      Riiiight. Because cryptography is identical to an 12-line string padding function.
      - fastball 11y ago
        I think that was smokeyj's point... the left-pad module is not going to have a "backdoor". nv-vn was creating a bit of a straw man, as no example or particular scenario in this article involved crypto.
deleted 11y ago
[deleted]
BinaryIdiot 11y ago
> Why waste time and lines of code implementing something so trivial when there is already a solution available? Because it's so trivial? I can't wrap my head around why this is an argument in the first place. It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add it to package.json and run npm install. People should be trying to limit dependencies where possible. Reproducible builds are really important if it costs you almost no time you should have it in your code base IMO. People taking the DRY principle to the most extreme degree always makes for the worst code to debug and maintain.
- deleted 11y ago
  [deleted]
- brightball 11y ago
  This entire comment thread is such a breath of fresh air. I was beginning to think that I was that guy who was crazy for thinking that all of the people doing this were crazy. This thread is like my new support group.
- lmm 11y ago
  > It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add it to package.json and run npm install. Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of custom code. > People should be trying to limit dependencies where possible. Reproducible builds are really important if it costs you almost no time you should have it in your code base IMO. That's a non sequitur. Reproducible builds are important, but unless you write code with 0 external dependencies you already have a system in place for handling library dependencies in a reproducible way. So why not use it? > People taking the DRY principle to the most extreme degree always makes for the worst code to debug and maintain. This is the opposite of my experience.
  - 11y ago
dozzie 11y ago
> I don't see anything wrong with using a pre-made left pad function. Why waste time and lines of code implementing something so trivial when there is already a solution available? I'll tell you why. The least important ones is that downloading such trivial module wastes bandwidth and resources in general (now multiply this by several hundred times, because of dependency fractal JS sloshes in). I would also spend much more time searching for such module than I would implementing the damn function. More important is that you give up the control over any and every bug you could introduce in such trivial function or module. You don't make it less probable to have those bugs (because battle-tested package! except, not so much in JavaScript, or Ruby, for that matter), you just make it much harder to fix them. And then, dependencies have their own cost later. You actually need a longer project, not a throw-away one, to see this cost. It manifests in much slower bug fixing (make a fix, find the author or maintainer, send him/her an e-mail with the fix, wait for upstream release, vs. make a fix and commit it), it manifests when upstream unexpectedly introduces a bug (especially between you making a change and you running `npm install' on production installation), it manifests when upstream does anything weird to the module, and it manifests in many, many other subtle and annoying ways.
- dandelany 11y ago
  Finding this module on NPM or npmsearch.com is pretty trivial compared to ensuring you implement this in a way that catches every edge case. > It manifests in much slower bug fixing I don't buy this at all, because I've done it myself many times. If you're waiting on a PR from the original repo owner to fix a Production bug, you're doing it wrong. It's trivial to copy the dependency out of node_modules and into your src, and then fix the bug yourself. Then when the owner accepts your PR, swap it back in. I don't understand the problem here.
  - mbrock 11y ago
    What are these arcane edge cases everyone is so afraid of?
    - kungtotte 11y ago
sina 11y ago
I agree that Lodash would be a better choice because it seems like a well maintained project. There could be two counter args, in theory: - if the programmer uses other functions included in Lodash his code will have a single larger point of failure. For example, if Lodash is unpublished (intentionally as in this case, or unintentionally) then the programmer will have a lot more work to redo. - Lodash introduces a lot of code, while the programmer only needs one of its functions to pad a string.
- TheAceOfHearts 11y ago
  I'd be amazed if lodash were unpublished. Using a library like lodash makes a lot more sense once you use a module bundler that allows tree shaking (like Rollup or Webpack 2.0) along with the ES6 module syntax. Heck, even if you're just using babel with Browserify or Webpack 1.x, you can use babel-plugin-lodash [0] so it'll update your imports and you only pull in what you need. [0] https://github.com/lodash/babel-plugin-lodash https://github.com/lodash/babel-plugin-lodash
insin 11y ago
Every function in Lodash is also available as a dedicated module, for the same reason left-pad existed: https://www.npmjs.com/package/lodash.padstart https://www.npmjs.com/package/lodash.padstart
Estragon 11y ago
If it was a good implementation, I'd agree with you, but it's not: https://github.com/azer/left-pad/pulls https://github.com/azer/left-pad/pulls

zbuttram 11y ago

Some of the libraries people were mentioning broke yesterday already have lodash as dependencies, I have no idea why they wouldn't have just been using this...

zbuttram 11y ago
Someone mentioned below that lodash had some breaking changes related to the padding functions a couple times, which could be a totally valid reason to avoid using those. I was under the impression that the lodash API was more stable than to have that kind of thing happening.
- jdd 11y ago
  Lodash renamed padding on a major version bump (which requires opting into) to better align with the ES7 proposal. Nothing was done in a way to pull the rug out from underneath folks.

fweespee_ch 11y ago

> However, I agree it is ridiculous to have a dedicated module for that one function. For most nontrivial projects I just include lodash, which contains tons and tons of handy utility functions that save time and provide efficient, fast implementations of solutions for common tasks. I think that was largely the OP's point tbh. Using something like lodash [a utility library] is fine while using a module [for a single function] is not. It might have gotten lost in the ranting from on high but I don't think the author truly meant more than that.

Twirrim 11y ago
For what it's worth, that's what I read in to it too.

chipotle_coyote 11y ago

I think the article's thesis is essentially that every dependency your project pulls in -- which includes all the dependencies your dependencies pull in -- is a point of potential failure. I understand the "don't re-invent the wheel" defense, but the Node/JavaScript ecosystem tacitly encourages its users to build vehicles by chaining together dozens of pre-made wheels, all of which depend on more wheels, and each and every one of those wheels has a small but non-zero chance of exploding the next time you type "npm update." (And, y'know, maybe it's because I'm not a JS programmer, but the notion of looking for a module to implement a string padding function would never have even occurred to me.)

joantune 11y ago
The problem is not that, the problem is depending on unreleased versions, instead of simply depending on the version that was written when u wrote your code. a Git submodule like approach would be much better
nv-vn 11y ago
Worse yet, a backdoor or legitimate bug in any of these module could leave huge exploits in the entire Node.js ecosystem.
- smokeyj 11y ago
  Worse yet, the OS is compromised. This is why I hand roll all my encryption libraries. /s
  - cyphar 11y ago
    Riiiight. Because cryptography is identical to an 12-line string padding function.
    - fastball 11y ago
      I think that was smokeyj's point... the left-pad module is not going to have a "backdoor". nv-vn was creating a bit of a straw man, as no example or particular scenario in this article involved crypto.

deleted 11y ago

[deleted]

BinaryIdiot 11y ago

> Why waste time and lines of code implementing something so trivial when there is already a solution available? Because it's so trivial? I can't wrap my head around why this is an argument in the first place. It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add it to package.json and run npm install. People should be trying to limit dependencies where possible. Reproducible builds are really important if it costs you almost no time you should have it in your code base IMO. People taking the DRY principle to the most extreme degree always makes for the worst code to debug and maintain.

deleted 11y ago
[deleted]
brightball 11y ago
This entire comment thread is such a breath of fresh air. I was beginning to think that I was that guy who was crazy for thinking that all of the people doing this were crazy. This thread is like my new support group.
lmm 11y ago
> It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add it to package.json and run npm install. Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of custom code. > People should be trying to limit dependencies where possible. Reproducible builds are really important if it costs you almost no time you should have it in your code base IMO. That's a non sequitur. Reproducible builds are important, but unless you write code with 0 external dependencies you already have a system in place for handling library dependencies in a reproducible way. So why not use it? > People taking the DRY principle to the most extreme degree always makes for the worst code to debug and maintain. This is the opposite of my experience.
- 11y ago

dozzie 11y ago

> I don't see anything wrong with using a pre-made left pad function. Why waste time and lines of code implementing something so trivial when there is already a solution available? I'll tell you why. The least important ones is that downloading such trivial module wastes bandwidth and resources in general (now multiply this by several hundred times, because of dependency fractal JS sloshes in). I would also spend much more time searching for such module than I would implementing the damn function. More important is that you give up the control over any and every bug you could introduce in such trivial function or module. You don't make it less probable to have those bugs (because battle-tested package! except, not so much in JavaScript, or Ruby, for that matter), you just make it much harder to fix them. And then, dependencies have their own cost later. You actually need a longer project, not a throw-away one, to see this cost. It manifests in much slower bug fixing (make a fix, find the author or maintainer, send him/her an e-mail with the fix, wait for upstream release, vs. make a fix and commit it), it manifests when upstream unexpectedly introduces a bug (especially between you making a change and you running `npm install' on production installation), it manifests when upstream does anything weird to the module, and it manifests in many, many other subtle and annoying ways.

dandelany 11y ago
Finding this module on NPM or npmsearch.com is pretty trivial compared to ensuring you implement this in a way that catches every edge case. > It manifests in much slower bug fixing I don't buy this at all, because I've done it myself many times. If you're waiting on a PR from the original repo owner to fix a Production bug, you're doing it wrong. It's trivial to copy the dependency out of node_modules and into your src, and then fix the bug yourself. Then when the owner accepts your PR, swap it back in. I don't understand the problem here.
- mbrock 11y ago
  What are these arcane edge cases everyone is so afraid of?
  - kungtotte 11y ago

sina 11y ago

I agree that Lodash would be a better choice because it seems like a well maintained project. There could be two counter args, in theory: - if the programmer uses other functions included in Lodash his code will have a single larger point of failure. For example, if Lodash is unpublished (intentionally as in this case, or unintentionally) then the programmer will have a lot more work to redo. - Lodash introduces a lot of code, while the programmer only needs one of its functions to pad a string.

TheAceOfHearts 11y ago
I'd be amazed if lodash were unpublished. Using a library like lodash makes a lot more sense once you use a module bundler that allows tree shaking (like Rollup or Webpack 2.0) along with the ES6 module syntax. Heck, even if you're just using babel with Browserify or Webpack 1.x, you can use babel-plugin-lodash [0] so it'll update your imports and you only pull in what you need. [0] https://github.com/lodash/babel-plugin-lodash https://github.com/lodash/babel-plugin-lodash

insin 11y ago

Every function in Lodash is also available as a dedicated module, for the same reason left-pad existed: https://www.npmjs.com/package/lodash.padstart https://www.npmjs.com/package/lodash.padstart

Estragon 11y ago

If it was a good implementation, I'd agree with you, but it's not: https://github.com/azer/left-pad/pulls https://github.com/azer/left-pad/pulls