Hacker News Reader

Comment by 0xAFFFF | Hacker News Reader

If anything, the left-pad debacle has shown that NPM package granularity has gone way too small, at a point where package overhead was outweighing the package simplicity benefits.

View on HN

Left-pad was made at a time when tree-shaking wasn't really around, so it was good practice to only include the functions you needed to avoid making websites too heavy. If you just needed a small function then it'd be silly to include a huge utility library like Underscore.

You're missing the point. Nobody with a serious background in software development should ever need to pull in a package to pad a string or check if a number is even or odd. If someone is smart enough to use a package manager, they should be more than capable to write a function to pad a string (assuming the standard library doesn't include one already)!

How does serious background help the argument for wasting your time writing code that's already been written. By the way, why should serious people use padding from the standard library?

I would argue that a leftpad/is-odd package is the equivalent of writing a for loop. The time it cost you to search the internet, download the package, and rerun your build script cost more than the time to write the function from scratch and the behavior is indentical.

Duplicate code across the ecosystem is fine. Not every function must be unique for an entire programming language.

What about the time it cost you to search the internet, read the docs, and use the one from std? How many seconds does each variant take (with hot/cold memory cache?)

And the behavior could also be worse, there is no guarantee of perfection.

The last argument is too generic to offer any guidance. Why is it better for this function be duplicated?? Should it not be part of std to avoid uniqueness?

> Should it not be part of std to avoid uniqueness?

> > > > (assuming the standard library doesn't include one already)

This doesn't address the should

The standard library is a far less risky dependency than third-party libraries. It's far more reliable in presence and behavior.

While you are correct, the problem compounds when popular package developers choose to use tiny packages.

I don't need left-pad.

But maybe I need react-starter-kit.

Now, imagine that react-starter-kit has a dependency to markdown-js-blobber, which has a dependency to make-text-nice, which has a dependency to left-pad.

In this scenario I am now "pulling in a package to pad a string". If I am "smart enough to use a package manager", I should be "more than capable to write..." an alternative to react-starter-kit..?

The onus there is on the "make-text-nice" developer, not an eventual user of "make-text-nice".

I don't place any blame here on the person using `react-starter-kit` and I think you're being a bit obtuse to suggest otherwise. It's the original person who pulled in a package for <10 lines of code who is to blame.

I provided the real reason for the high download counts of these packages.

However, JavaScript never had a proper standard library.

Combine this to mainstream education teaching that you should always reuse code when possible instead of "reinventing the wheel", and web shops agreeing to it because "using libraries saves time", and it's easy to understand the "popularity" of left-pad.

To a certain extent, and to the best of my knowledge, those things haven't really changed.

Ironically I feel like this is something LLMs will improve. Now anyone can type "create left pad function" and it will essentially just vendor in the existing code.

What does the size or granularity have to do with the incident? If the author had combined all his 350+ packages into one (or had had a more comprehensive text-utils.js package) and pulled that instead, the issue would have been at least as severe?

I don’t think such small packages are sensible, in particular when versioned separately, but I also don’t see how the left-pad debacle has shown that.

Reply on news.ycombinator.com