Why Java can have reliable utility libraries such as Apache Commons and Google Guava, but JS somehow cannot?
Left-Pad (2024)
51–60 of 224 posts
Re: Left-Pad (2024)
#52Earlier quoted context omitted.
I think this is the biggest irony of it: the kik package, which kik where so desperate to have, is basically sweet Fanny Adams. Also, Kik turn out to be negligent and pretty scummy. There was some controversy with them involving crypto, but the main thing I remember about them is that Kik is rife in terms of trading pornography, including child pornography, as discussed on this Darknet Diaries episode: https://darkne…
>Also, Kik turn out to be negligent and pretty scummy. turns out? they threatened a pre-existing naming collision with legal action and bullied the platform first into forcing the name to be theirs, and then afterwards by crying to npm until their software tests passed again. they began scummy.
So my friend sensibly caved in and changed the name of the package, got on with his life, and now it's all long forgotten history.
Going back to Kik, before I knew about all the other stuff (which I only found out about when I listened to that Darknet Diaries episode last year - bit late to the party there) I simply thought they'd gone about defending their trademark in a hamfisted and douchey way that had got Azer's back up. Lawyer's gonna lawyer, and the way they did it I thought they were douchebags, but beyond that I didn't give it much consideration. There was certainly no way any of this even hinted to me that they were negligently facilitating the distribution of child porn[0].
[0] Yes, this is obviously against Kik's ToS, but ToS are only worth anything if they're enforced whereas - certainly at times prior to the Darknet Diaries episode being released in 2021 - there was at best inconsistent and ineffective enforcement of these terms. I have no insight into the current situation with Kik.
Re: Left-Pad (2024)
#53It's a minor thing, but: > Most of my open source work followed Unix philosophy, so the packages did one thing at a time. Nobody has suggested that libc -- to take the most obvious example -- is against the Unix philosophy. Debates occur around whether whether commands / daemons do too much (recent poster child being systemd) or aren't composable.
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.
Re: Left-Pad (2024)
#54Why Java can have reliable utility libraries such as Apache Commons and Google Guava, but JS somehow cannot?
Re: Left-Pad (2024)
#55Re: Left-Pad (2024)
#56Re: Left-Pad (2024)
#57left-pad even being a package is pretty funny, no? How many bytes got pumped across CDNs, proxies, build pipelines, etc. just to write a tiny utility function? I'm all for taking advantage of existing solutions, but I can't wrap my head around needing to pad a string and thinking "oh, I bet there's a package for that"
Re: Left-Pad (2024)
#58left-pad even being a package is pretty funny, no? How many bytes got pumped across CDNs, proxies, build pipelines, etc. just to write a tiny utility function? I'm all for taking advantage of existing solutions, but I can't wrap my head around needing to pad a string and thinking "oh, I bet there's a package for that"
Really, what's the qualitative difference between reaching for a utility function that someone else already wrote within your project and reaching for a package that someone else already published within your ecosystem? They're obviously not the same thing but are they so far apart that you can't wrap your head around it wanting to treat them the same, given sufficiently advanced tooling?
The package has to have a public API, meet millions of different people's use cases, and any change to the API will cause millions of man-hours of useless work... and yet if it's a poorly designed API, it might cause millions of sub-optimal programs.
Every project has a StringUtils file. But every project's StringUtils file is different.
Published packages in an ecosystem ought to be well-designed, with good performance, good APIs, good security. Packages that don't meet that bar ought to be kept out. npm is jarring because it let any old shit get published, despite there being long-standing package ecosystems in other languages with much better standards, that they could have copied from (CPAN, PyPi, RubyGems, Maven Central, NuGet Gallery, etc.)
Re: Left-Pad (2024)
#59Earlier quoted context omitted.
> On March 18, 2016, Isaac Z. Schlueter, the chief executive officer of npm, Inc., wrote to both Kik Interactive and Koçulu, stating that the ownership of the kik package would be manually transferred to Kik Interactive. > After Koçulu expressed his disappointment with npm, Inc.'s decision and stated that he no longer wished to be part of the platform, Schlueter provided him with a command to delete all 273 modules t…
Ok fair! In that case I actually agree with his stance I think. I can understand how isaacs messed this up in what must've been a stressful situation, but it's hard to blame the author for it indeed, if he was just running the commands provided.
Re: Left-Pad (2024)
#60Earlier quoted context omitted.
It wasn’t the first package manager for a programming language and plenty of us pointed out the folly of packages that small. Npm (and JS in general) is a victim of fashion, primarily.
I think that statement is parsed as "npm was the first incredibly accessible package manager for [server-side JavaScript, which at the time was] an emergent popular technology,"