Comment by cogman10 | Hacker News Reader

Comment by cogman10 | Hacker News Reader

Parent Full thread

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.

> "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.

> 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.

> 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...

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

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.

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.

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

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

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

`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.

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

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?

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.

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

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

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.

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

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.

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

Within the last year even

MooTools springs to mind

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)

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.

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

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

Reply on news.ycombinator.com