> Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past.
It's not wrong, but this take is kind of tired and well out of date. For about a decade or so left-pad's functionality has been standard in all browsers or runtimes. Plenty of other micropackages have been obsoleted as well and the current zeitgeist is to avoid publishing or using any sort of micropackage.
"Zero dependencies" is now a top marketing term in the frontend world. Unfortunately, their removal is an ongoing process and it's taken way too long already to fully purge the ecosystem of these packages. However, it's not because the JavaScript community has never thought of this issue before. "Add more features to the JS standards and don't use is-number" is not a particularly new idea or valuable insight.
But beyond that, there were plenty of not-tiny packages impacted as well. Continuing to beat this dead horse may be fun, but it distracts from the actual issue here.
root_axis · 40m ago
I've already heard suggestions in my org that we begin to use LLMs to generate entire NIH stacks from the ground up. I'm tired boss.
> Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past. This could be combined with a consolidation of efforts, merging micro-libraries into larger packages with a more coherent and holistic scope and purpose, which prune their own dependency trees in turn.
This is as big as a strawman as I can imagine. Both of these "solutions that won't happen" are already happening:
- The ECMAScript standard already defines a `Strong.padStart()` as part of the "real" standard library of Javascript [1]
- There is a very well known larger package that combines many micro-utilities like this into one, lodash [2]
> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of software development.
Really seems like the author wants to hate on the ecosystem for the sake of hating on it.
Yeah, we’re at the point now where people saying left-pad isn’t fixed is more of an indicator that they aren’t paying attention. I’ve largely stopped correcting people, as it’s clear there’s a sizable community that just likes being grumpy about JS and doesn’t appreciate reality barging in to ruin the fun.
mrbluecoat · 40m ago
> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of [X].
[X]
"software development"
"climate change"
"healthcare reform"
"political polarization"
...
sobiolite · 48m ago
Won’t this be solved fairly soon when package managers have automatic scanning of updates by AIs that are superhumanly good at spotting malicious code?
root_axis · 36m ago
Not sure if this is sarcastic, but this is a terrible idea. Best case scenario, it relaxes human vigilance and turns the success of malicious code attacks into a dice roll. More likely is that obfuscation techniques designed to fool LLMs will open the flood gates for malicious code.
latchkey · 1h ago
Pnpm has a new setting to stave off supply chain attacks
It’s not great. If an urgent security patch needs to be applied, the package must be excluded entirely from the minimum age requirement. There is no way to allow just a single version.
shadowgovt · 55m ago
Fundamentally, the fix isn't technical; it's social / structural.
Companies either hold themselves accountable for signing off on the dependencies they use, hold the repos accountable for signing off the dependencies, or keep doing what we've been doing.
It's not wrong, but this take is kind of tired and well out of date. For about a decade or so left-pad's functionality has been standard in all browsers or runtimes. Plenty of other micropackages have been obsoleted as well and the current zeitgeist is to avoid publishing or using any sort of micropackage.
"Zero dependencies" is now a top marketing term in the frontend world. Unfortunately, their removal is an ongoing process and it's taken way too long already to fully purge the ecosystem of these packages. However, it's not because the JavaScript community has never thought of this issue before. "Add more features to the JS standards and don't use is-number" is not a particularly new idea or valuable insight.
But beyond that, there were plenty of not-tiny packages impacted as well. Continuing to beat this dead horse may be fun, but it distracts from the actual issue here.
This is as big as a strawman as I can imagine. Both of these "solutions that won't happen" are already happening:
- The ECMAScript standard already defines a `Strong.padStart()` as part of the "real" standard library of Javascript [1]
- There is a very well known larger package that combines many micro-utilities like this into one, lodash [2]
> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of software development.
Really seems like the author wants to hate on the ecosystem for the sake of hating on it.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://lodash.com/
[X]
"software development"
"climate change"
"healthcare reform"
"political polarization"
...
https://news.ycombinator.com/item?id=45286526
yarn feat: implement npmMinimumReleaseAge and npmMinimumReleaseAgeExclude config options
https://github.com/yarnpkg/berry/pull/6901
Companies either hold themselves accountable for signing off on the dependencies they use, hold the repos accountable for signing off the dependencies, or keep doing what we've been doing.
The third option is amortized cheapest.