I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account
Like seriously... at 50 million downloads maybe you should vendor some shit in.
Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger than the minified version of this code!
At one point in the past like 5% of create-react-app's dep list was all from one author who had built out their own little depgraph in a library they controlled. That person also included download counts on their Github page. They have since "fixed" the main entrypoint to the rats nest though, thankfully.
> There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them.
> entirely for the purpose of getting high download counts on their github account
Is this an ego thing or are people actually reaping benefits from this?
Anthropic recently offered free Claude to open source maintainers of repositories with over X stars or over Y downloads on npm. I suppose it is entirely possible that these download statistics translate into financial gain...
I'm completely apathetic about spicy autocomplete for coding tasks and even I wonder which terrible code would be worse.
The guy who wrote is even/odd was for ages using a specifically obscure method that made it slower than %2===0 because js engines were optimising that but not his arcane bullshit.
from a security perspective this is even worse than it looks. every one of those micro packages is an attack surface. we just saw the trivy supply chain get compromised today and thats a security tool. now imagine how easy it is to slip something into a 7 line package that nobody audits because "its just a utility." the download count incentive makes it actively dangerous because it encourages more packages not fewer.
I remember seeing this one guy who infiltrated some gh org, and then started adding his own packages to their dependencies or something to pad up his resume/star count.
As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing.
If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".
I think the fact that everyone cites the same is-number package when saying this is indicative of something though.
Like I legit think that we are all imagining this cultural problem that's widespread. My claim (and I tried to do some graph theory stuff on this in the past and gave up) is that in fact we are seeing something downstream of a few "bad actors" who are going way too deep on this.
I also dislike things like webpack making every plugin an external dep but at least I vaguely understand that.
The point isn't that everyone needs to write the same code manually necessarily. It's that an author could easily just combine the entire tree of seven line packages into the one package the create-react-app uses directly. There's no reason to have a dozen or so package downloads each with seven lines of code instead of one that that's still under under a hundred lines; that's still a pretty small network request, and it's not like dead code analysis to prune unused functions isn't a thing. If you somehow find yourself in a scenario where you would be happy to download seven lines of code, but downloading a few dozen more would be an issue, that's when you might want to consider pasting the seven lines of code manually, but I honestly can't imagine when that would be.
The article and (overall) this comments section has thankfully focused on the problem domain, rather than individuals.
As the article points out, there are competing philosophies. James does a great job of outlining his vision.
Education on this domain is positive. Encouraging naming of dissenters, or assigning intent, is not. Folks in e18e who want to advance a particular set of goals are already acting constructively to progress towards those goals.
People aren't criticizing the development philosophy in this subthread. This has been done by the article itself and by several people before.
What people are criticizing is the approach in pushing this philosophy into the ecosystem for allegedly personal gain.
The fact that this philosophy has been pushed by a small number of individuals shows this is not a widespread belief in the ecosystem. That they are getting money out of the situation demonstrates that there is probably more to the philosophy than the technical merits of it.
As usual, he's copying someone else who's been doing this for years:
https://www.npmjs.com/package/is-number - and then look and see shit like is odd, is even (yes two separate packages because who can possibly remember how to get/compare the negated value of a boolean??)
Honestly for how much attention JavaScript has gotten in the last 15 years it's ridiculous how shit it's type system really is.
The only type related "improvement" was adding the class keyword because apparently the same people who don't understand "% 2" also don't understand prototypal inheritance.
That's a good point, it's only been around for 30 years, and used on 95% of websites. It's not really popular enough for a developer to take an hour or two to read how it works.
The word "used" is doing some heavy lifting there. Not all usage is equal, and the fact that it's involved under the hood isn't enough to imply anything significant. Subatomic physics is used by 100% of websites and has been around for billions of years, but that's not a reason to expect every web developer to have a working knowledge of electron fields.
Let's compromise and say that whoever is responsible for involving (javascript|electron fields) in the display of a website, should each understand their respective field.
I don't expect a physicist or even an electrical engineer or cpu designer to necessarily understand JavaScript. I don't expect a JavaScript developer to understand electron fields.
I do expect a developer who is writing JavaScript to understand JavaScript. Similarly I would expect the physicist/etc to understand how electrons work.
I don't exactly know the system for which restaurants pull out of the disposable chopsticks but I think that for example "normal" tempura, katsudon, or like soba restaurants will tend to be those.
I almost associate the cheapo reusable plastic chopsticks with some food courts or Matsuya at this point.
You come to my house to have food. I serve the food on obviously unclean dishes. Is that not rude as well? Do you just use the obviously dirty, nasty, used dishes out of not wanting to appear rude?
Do I just use chopsticks that will put splinters in my mouth just to not appear rude?
In your metaphor the equivalent would be that you see that the chopsticks have splinters and are cleaning it
But everyone I met who does splinter cleanup does it _every time_ even without a cursory inspection. So the metaphor is… maybe more apt that you are cleaning a plate despite not seeing whether it’s clean or not first
This is a stupidly annoying problem because it's _very easy_ to accidentally spawn children that won't get killed up in many kill situations because the distinction between processes and process groupes papered over by the fact that shells will be nice enough to kill via process group.
But if your program is some TUI in raw mode its ctrl+c handler is often just killing itself... leaving its children along! Process groups in Unix are a stupid mess and the default being "a process can go away with the subprocess sticking around" rather than the inverse has just caused so many of these long-standing issues.
Is it a lock? I buy a building and the builder put an id verification lock on the doors and I am not allowed to remove it. And they also require a separate one time fee of 2 to 5 percent of the purchase price.
In physical world, there’s only so many people who can rob you if you do something stupid (like constantly give away copies of your keys to strangers), they will be very noticeable when they are doing so, and if you feel like something’s off you can always change the lock.
On the Internet, an you are fair game to anyone and everyone in the entire world (where in some jurisdictions even if it’s known precisely who is the figurative robber they wouldn’t face any consequences), you could get pwned as a result of an undirected mass attack, and if you do get pwned you get pwned invisibly and persistently.
Some might say in these circumstances the management company installing a (figurative) biometric lock is warranted, and the most reliable way to stop unsuspecting residents from figuratively giving access to random masked strangers (in exchange for often very minor promised convenience) is to require money to change hands. Of course, that is predicated on that figurative management company 1) constantly upping their defences against tenacious, well-funded adversaries across the globe and 2) themselves being careful about their roster of approved trusted parties, whom they make it easy to grant access to your premises to.
The trouble with your analogy is that physical reality works the same way. People have been committing mail fraud since the advent of post offices. Spies have been planting bugs on delivered goods since the invention of bugs. The thing that causes this isn't digital devices, it's long-distance delivery of goods and messages.
Meanwhile installing software on your own device is the thing that isn't that. They're preventing it even when you're the owner of the device and have physical access to it. They're not installing a lock so that only you can get in, they're locking you out of your own building so they can install a toll booth on the door.
totally my point here. The actual shape of the thing starts mattering so much that at one point your metaphor is just completely useless for judging the actual tradeoffs
it already has a lock, by default you're not allowed to install apps in android you have to accepts a bunch of prompts and configurations (the key) and now you won't even have the key
uvs success is downstream of paying like 10 very good rust tooling developers to work on uv full time.
Full time effort put into tools gets you a looooot of time to make things work well. Even ignoring the OSS stuff, many vendors seem to consider their own libs to be at best “some engineers spend a bit of time on them” projects!
Yeah, it's pretty hard to argue that at least for the python tooling use case, the typical open source methodologies had failed to solve things as well in a couple decades as uv did in a few years as a startup. The lesson we should take from that is probably more up for debate.
How is uv awesome and Poetry so bad? They do basically the same things except Astral re-invents the wheel but only part way instead of just relying on the existing tools. uv is fast. As far as I can tell, there's hardly any difference in functionality except for it also replacing PyEnv, which I never use anyway.
uv assuming your local Python is busted to hell and back helps a lot with isolation.
Poetry's CLI would often, for me, just fall over and crash. Crashing a lot is not a fundamental problem in the sense you can fix the bugs, but hey I'm not hitting uv crashes.
pipenv was even worse in terms of just hanging during package resolution. Tools that hang are not tools you want in a CI pipeline!
The end result: `uv run` I expect to work. `pipenv` or `poetry` calls I have to assume don't work, have to put retries into CI pipelines and things like that.
uv has a lot of sensible defaults that prevent clueless developers to shoot their own feet. Uv sync, for example, would uninstall packages not in pyproject.toml
i kind of disagree with this. uv run is clunky, i don't want that. i want to keep the activate the venv and do shit model. i hate uv run as a primitive.
I don't know if it's still true, but ~7 years ago when I last looked at it, Poetry didn't have the kind of UX I have in mind (That Astral/UV do). I remember trying to make it work, and it would choose Python 2 for some reason, despite me never having used it, and it having been obsoleted years before. I remember hitting many problems/errors I can't recall the detail of, but bad UX.
Living through it... Python 3 made a lot of changes for the better but 3.0 in particular included a bunch of unforced errors that made it too hard for people to upgrade in one go.
It wasn't until much later (I would say 3.4 or 3.5?) that we had good tooling to allow for migrating from Python 2 to Python 3 gradually, which is what most tools needed to do.
The final thing that made Python upgrading easy was making a bunch of changes (along with stuff like six) so that you could write code that would run identically in Python 2 and Python 3. That lets you do refactors over time, little cleanups, and not have the huge "move to Python 3" commit.
Like seriously... at 50 million downloads maybe you should vendor some shit in.
Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger than the minified version of this code!
At one point in the past like 5% of create-react-app's dep list was all from one author who had built out their own little depgraph in a library they controlled. That person also included download counts on their Github page. They have since "fixed" the main entrypoint to the rats nest though, thankfully.
https://www.npmjs.com/package/has-symbols
https://www.npmjs.com/package/is-string
https://github.com/ljharb
reply