[cxr]

You'll never get NPM apologists to acknowledge this. One of their only skills is making non-specific appeals to the necessity of it all (as essential infrastructure) and vague arguments that boil down to "you need to trust the wisdom of the crowds" (and e.g. the fact that it exists and everyone else is using it means that anyone who disputes its value just doesn't understand it—bonus points for them if they manage to work in a slight that's designed to paint you, implicitly or explicitly, as a junior), despite not being able to attest to any firsthand knowledge of the real why of anything they're defending.

> The new dependencies were all polyfills for JavaScript functions that have long been supported everywhere. The Object.defineProperties method for example was shipped as part of the very first public Node 0.10.0 release dating back to 2013. Heck, even Internet Explorer 9 supported that. And yet there were numerous packages in that dependend on a polyfill for it.

[cogman10]

Back in 2011ish or so when npm was just getting started and Ruby on rails was all the rage. "Do not repeat yourself" was seen as a gold standard for programming. The end result has been a mess, particularly for npm. There were FAR too many articles talking about how "there's no such thing as too small a dependency" and talks given about how much a virtue it was to create "is-odd" or "is-even" "look you saved 3 lines of code that you don't have to test!"

Unfortunately, that compounded with browser of the era (Internet explorer...) having basically 0 support for modern javascript led to a proliferation of dependencies, polyfills, etc that are nearly impossible to remove from the ecosystem.

I've not seen a lot of node apologists that are fine with the current ecoystem. The problem is righting the ship is going to be terribly hard. Either existing frameworks/libraries need to go through the effort of saying "Ok, do I really need is-even, let's remove it" or we need new frameworks/libraries to abandon tools and the ecosystem in favor of fatter and fewer dependencies.

I think the issue all stems from the fact that before 2010ish, there was one library and one framework, jquery (Ok, there were others... but were there really?) and that added a good 1mb to any webpage. The notion was we do more with less if we had a bunch of smaller deps that didn't need to be brought in.

[josephg]

> "Do not repeat yourself" was seen as a gold standard for programming.

I remember this era. I’ve been using nodejs before npm existed and so many silly things have happened in that time.

I think the core problem the JS ecosystem has always had is that most JS developers are relatively inexperienced. (JS is very beginner friendly and this is the price we pay). I still vividly remember being at nodecamp in 2012 or something listening to someone tell me how great it would be if the entire OS was written in javascript. It didn’t matter how much I poked and prodded him, he couldn’t hear that it might not be an amazing idea. I think he thought it would be easier to reimplement an OS kernel in JS than it would be to just learn C. And there were lots of people around with a sparkle in their eye and those sort of wacky ideas - good or bad. It was fun and in hindsight a very silly time.

So yeah, of course some idiot in JS made is-even. And is-odd (which depends on is-even). I see all of this as the characteristic mistake of youth - that we go looking for overly simple rules about what is good and bad (JS good! C bad!) and then we make a mess. When we’re young we lack discernment about subtle questions. When is it better to pull in a library vs writing it yourself inline? When is JS a good or a bad idea? When should you add comments, or tests? And when do you leave them out?

Most of the best engineers I know made these sort of stupid philosophical mistakes when they were young. I certainly did. The JS ecosystem just suffers disproportionately from this kind of thing because so many packages in npm are written by relatively new developers.

I think that’s a good thing for our industry as a whole. But I also get it when Bryan Cantrill describes JS as the failed state of programming languages.

[TeMPOraL]

> The JS ecosystem just suffers disproportionately from this kind of thing because so many packages in npm are written by relatively new developers.

I think it also suffers because it grew in the age of Internet and Open Source, which made the problem compounding. Programmers write a lot of stupid code when learning, it's part of the process - but it used to be that the stupidity was constrained to your machine and maybe a few poor souls who ended up reading or using your code. In JS ecosystem, all that stupidity gets published, and ends up worming its way, through dependency chains, into everything.

[phire]

> I still vividly remember being at nodecamp in 2012 or something listening to someone tell me how great it would be if the entire OS was written in javascript.

That reminds me of Gary Bernhardt's "The Birth & Death of JavaScript" talk[0], which one of the best comedy programming talks. Despite the comedy, it's also a half-decent idea.

[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

[beepbooptheory]

I thought is-even/is-odd were satirical? Granted, satire echoing these same points... but, you know, just for-the-record.

[technion]

Although it's unclear, every time someone provides a one liner there are staunch not satire arguments about "covering edge cases you didn't think of" and I disagree. Look at the actual code: https://github.com/i-voted-for-trump/is-odd/

There's a "tested edge case" where you can check isOdd('1') and it will work - to me the code is already wrong, isOdd(STRING) should throw. The correct solution is to use Typescript and assert the input is a number.

The Number.isSafeInteger check is an interesting one. Yes, it's not "safe" to work with a number outside this but no doubt something in the function would be broken before an is-odd check if it was relied upon.

Often the edge case someone else catered to is something counter to my expectation. I would rather write two lines of code myself and be aware of the behaviour.

[phire]

It's hard to tell.

The author of both packages has since moved the github repos to an organisation named "i-voted-for-trump" and labelled the packages with the "troll-bait" tag.

But the author also claims those packages where created when they were learning to program, and they seem to have stuck with the idea of small libraries (just not quite that small). The changes seem to be due to grief the programming community has given him about those packages, as some of the worst examples of the pattern.

I suspect the author was being slightly satirical by choosing to do the simplest possible NPM library. But at the same time they probably believed it was a useful package, allowing new programmers (like himself) to calculate the evenness/oddness of numbers without needing to know or google the mod-2 trick. And if you are going to learn how to create npm packages, might as well start small.

If they were aiming to be slightly satirical, they were not expecting that level of outrage.

It's worth pointing out that the libraries do slightly more than just mod-2. It checks the argument passed in was actually an integer, and throws descriptive error messages if the argument is not a number or not an integer.

[lenkite]

There were packages for every color code in npm at one time.

[pphysch]

Those may be satirical, but `leftpad` is real.

https://qz.com/646467/how-one-programmer-broke-the-internet-...

[corbezzoli]

`left-pad` is the perfect amount of complexity and "I'm sure I can do it" ability by everyone who looks at it. I want you to write that logic and not have some stupid mistake that was fixed in that module 15 years ago.

Now we have String.prototype.padStart thanks to that debacle.

[pphysch]

Then copy-paste it from SO^H^H your LLM copilot. It's clearly not something that benefits from being an external dependency.

[whstl]

Most people fine with the problems of the ecosystem have financial incentives.

Stating that you maintain 800 NPM libraries brings more clout and money than maintaining a foundational one.

Even with foundational packages things tend to go wrong. Why add features to an existing package if I can write several plugins? Or even worse in some cases: why use the existing configuration file if I can instead just ask users to install dozens of dummy packages that only exist to trigger a feature in my Core package?

[tored]

There was a closely related movement at the time that called for that languages should have minimal "bloat", combined that with importing only what you need down to single functions, it was viewed as the future of programming.

I was sympathetic to that idea then, it sounded good in theory, however in practice it was horrible.

Today I enjoy coding in "bloated" languages with only a few external dependencies.

[no_wizard]

I wonder if there would be any interest from folks for an alternative npm registry that would automatically cleanup dependency chains like this (among other things, possibly), remove polyfills etc.

I always thought about something like this, with on the fly manipulation of packages via SWC would be pretty fast I think

[nicoburns]

I think a better approach would be automated tooling to detect opportunities for cleanup, and then submitting PRs to libraries.

[rschristian]

That only works if the maintainers of the packages are interested in the cleanup -- the maintainer behind some of the packages mentioned in this thread is very much not. They prefer the bloat to incrementing the major version number.

[bsimpson]

esm.sh kind of does this for livecoding environments (e.g. Codepen/Colab) where you're using <script type=importmap> instead of a bundler.

[Klonoar]

jQuery is the one that’s outlasted them all, but yes - there were absolutely other frameworks in use. It also discounts the detour into the Backbone era before Angular and React took off.

[paradox460]

I've interacted with devs who still bring in prototype.js

Within the last year even

[arbol]

MooTools springs to mind

[Klonoar]

MooTools, Prototype, Dojo, YUI... what an era.

It sometimes feels like part of what we deal with now in the JS world is due to half the crowd not knowing what came before.

(Edit: to be clear, I think the other half is responsible for the advancements... so it probably evens out)

[Izkata]

One of the systems I currently work on has all five of those. Which one was in use was developer's choice for pretty much any given page or feature.

[onli]

Is that with the 1MB a joke? Just in case it's not, jQuery never was that big, not even uncompressed.

[samus]

And one could download stripped-down versions with just the features needed. Important especially with jQuery UI since it had quite some heavy components.

[CharlesW]

> You'll never get NPM apologists to acknowledge this.

How should NPM prevent archaic dependencies, or the "even more bizarre" (author's words) problem of developers calling polyfills directly instead of the function that the polyfill fills?

[whstl]

The parent is not criticising NPM the tool/registry, but rather the ecosystem and culture.

[cxr]

I'm happy to criticize NPM the tool. The whole thing is designed as a second, crummier version control system that lives in disharmony with and on top of your base-level version control system (so it can subvert it). It's a terrible design.

There's basically at most one reasonable use for npm: as a glorified download manager, i.e. to quickly fetch a module by name (right before you check it in to version control with Git). This differs wildly, of course, from how it's actually used, which is as a drug that sweeps mountains of unaudited code under the rug so people can trick themselves and others into thinking that none of it's really there on the basis that it's not visible when anyone first clones the repo.

To answer the other commenter's question, "How should NPM prevent archaic dependencies": it shouldn't; it's okay for programmers to be responsible for their work.

[spankalee]

How is npm a version control system?

npm is a fairly standard package manager, much like many others, pretty good even.

I don't know of anyone who says that package managers and source control solve the same problems. They both happen to use the word and concept of "version" but to mean different things. Yes, some projects vendor in their dependencies into their source control system, but they must either manually verify package version compatibility or use a package manager like npm to help them do it. And vendoring doesn't work for actual packages published to the package repo. If they vendored dependencies then every dependency would be duplicated always, defeating the very purpose of a package manager!

[cxr]

> npm is a fairly standard package manager, much like many others

Yes.

> They both happen to use the word and concept of "version" but to mean different things.

Right. I think I covered that adequately.

> And vendoring doesn't work for actual packages published to the package repo.

What?

> If they vendored dependencies then every dependency would be duplicated always, defeating the very purpose of a package manager!

Yes. Alternatively:

Please clearly articulate the purpose of a package manager (in the sense of the term when it's used to describe npm and others). See if you can work it out so that you can state it in the form of a testable hypothesis (i.e. ideally in quantitative terms like MBs/GBs of disk space used, or network transit, or time to fetch—or anything that you think accurately reflects what you consider to be the value proposition that npm fulfills and which we can use to evaluate it in scenarios where it would or would not be a good fit).

[spankalee]

Man, this isn't hard.

The purpose of a packages manager is to allow me to describe the packages and versions that my own package depends on, and download compatible versions of those dependencies and their transitive dependencies in such a way that dependencies are shared and that my runtime can use them.

npm does that, as does Cargo, Pub, Gems, pip, etc.

[jeroenhd]

I don't see the problem, to be honest. Everybody is using this guy's work for free and then he needs to deal with complaints that it's not good enough, because it supports ancient browsers in a way that's not to their liking.

You can always fork the projects with this guy's polyfills if you want, but you'll end up forking quite the collection of projects. Most of them are very minor and only end up polyfilling anyway, so you can probably get rid of the packages you don't want in an afternoon. Fork them and maintain them yourself if you're so inclined, don't complain that the free work he's doing for you isn't to your specifications.

[davedx]

It is infuriating. I love the power of the node ecosystem but the total lack of critical thinking around it drives me bonkers.