Live data from Hacker News

My failed attempt to shrink all NPM packages by 5%

evanhahn.com

81–90 of 253 posts

Re: My failed attempt to shrink all NPM packages by 5%

#81

I mean 4-5% the size for 10-100x the time is not worth it.

That's not actually so straightforward. You pay the 10-100x slowdown once on the compressing side, to save 4-5% on every download - which for a popular package one would expect downloads to be in the millions.

The downloads are cached. The build happens on every publish for every CI build.

Re: My failed attempt to shrink all NPM packages by 5%

#82

The fact that you are pursuing this is admirable. But this whole thing sounds too much like work. Finding opportunities, convincing entrenched stakeholders, accommodating irrelevant feedback, pitching in meetings — this is the kind of thing that top engineers get paid a lot of money to do. For me personally open source is the time to be creative and free. So my tolerance for anything more than review is very low. And…

> What’s a little sad, is NPM should not be operating like a company with 1000+ employees. The “persuade us users want this” approach is only going to stop volunteers. They should be proactively identifying efforts like this and helping you bring it across the finish line. Says who? Says an engineer? Says a product person? NPM is a company with 14 employees; with a system integrated into countless extremely niche and…

Open source needs to operate differently than a company because people don’t have time/money/energy to deal with bullshit.

Hell. Even 15 employees larping as a corporation is going to be inefficient.

what you and NPM are telling us, is that they are happy to take free labor, but this is not an open source project.

> Engineers are obsessed with 2% optimizations here

Actually in large products these are incredible finds. But ok. They should have the leadership to know which bandwidth tradeoffs they are committed to and tell him immediately it’s not what they want, rather than sending him to various gatekeepers.

Re: My failed attempt to shrink all NPM packages by 5%

#83

Earlier quoted context omitted.

> What’s a little sad, is NPM should not be operating like a company with 1000+ employees. The “persuade us users want this” approach is only going to stop volunteers. They should be proactively identifying efforts like this and helping you bring it across the finish line. Says who? Says an engineer? Says a product person? NPM is a company with 14 employees; with a system integrated into countless extremely niche and…

Open source needs to operate differently than a company because people don’t have time/money/energy to deal with bullshit. Hell. Even 15 employees larping as a corporation is going to be inefficient. what you and NPM are telling us, is that they are happy to take free labor, but this is not an open source project. > Engineers are obsessed with 2% optimizations here Actually in large products these are incredible find…

Correct; NPM is not an "open source project" in the sense of a volunteer-first development model. Neither is Linux - over 80% of commits are corporate, and have been for a decade. Neither is Blender anymore - the Blender Development Fund raking in $3M a year calls the shots. Every successful "large" open source project has outgrown the volunteer community.

> Actually in large products these are incredible finds.

In large products, incredible finds may be true; but breaking compatibility with just 0.1% of your customers is also an incredible disaster.

Re: My failed attempt to shrink all NPM packages by 5%

#84
What about a different approach - an optional npm proxy that recompresses popular packages with 7z/etc in the background?

Could verify package integrity by hashing contents rather than archives, plus digital signatures for recompressed versions. Only kicks in for frequently downloaded packages once compression is ready.

Benefits: No npm changes needed, opt-in only, potential for big bandwidth savings on popular packages. Main tradeoff is additional verification steps, but they could be optional given a digital signature approach.

Curious if others see major security holes in this approach?

Re: My failed attempt to shrink all NPM packages by 5%

#86
I wonder what is the tarball size difference on average if you'd for example download everything in one tarball (full package list) instead of 1-by-1 as the gzip compression would work way better in that case.

Also for bigger companies this is not really a "big" problem as they usually have in-house proxies (as you cannot rely on a 3rd party repository in CI/CD for multiple reasons (security, audit, speed, etc)).

Re: My failed attempt to shrink all NPM packages by 5%

#87

The fact that you are pursuing this is admirable. But this whole thing sounds too much like work. Finding opportunities, convincing entrenched stakeholders, accommodating irrelevant feedback, pitching in meetings — this is the kind of thing that top engineers get paid a lot of money to do. For me personally open source is the time to be creative and free. So my tolerance for anything more than review is very low. And…

[deleted]

Re: My failed attempt to shrink all NPM packages by 5%

#88

Earlier quoted context omitted.

Yes and no. If I'm paying $5 a month for storage, I probably don't care about saving 5% of my storage costs. If I'm paying $50,000/month in storage costs, 5% savings is a lot more worthwhile to pursue

Doesn't npm belong to Microsoft? It must be hosted in Azure which they own so they must be paying a rock bottom rate for storage, bandwidth, everything.

It's probably less about MS and more about the people downloading the packages

Re: My failed attempt to shrink all NPM packages by 5%

#89

The fact that you are pursuing this is admirable. But this whole thing sounds too much like work. Finding opportunities, convincing entrenched stakeholders, accommodating irrelevant feedback, pitching in meetings — this is the kind of thing that top engineers get paid a lot of money to do. For me personally open source is the time to be creative and free. So my tolerance for anything more than review is very low. And…

I think that the reason NPM responded this way is because it was a premature optimization.

If/when NPM has a problem - storage costs are too high, or transfer costs are too high, or user feedback indicates that users are unhappy with transfer sizes - then they will be ready to listen to this kind of proposal.

I think their response was completely rational, especially given a potentially huge impact on compute costs and/or publication latency.

Re: My failed attempt to shrink all NPM packages by 5%

#90

The fact that you are pursuing this is admirable. But this whole thing sounds too much like work. Finding opportunities, convincing entrenched stakeholders, accommodating irrelevant feedback, pitching in meetings — this is the kind of thing that top engineers get paid a lot of money to do. For me personally open source is the time to be creative and free. So my tolerance for anything more than review is very low. And…

While NPM is open source, it's in the awkward spot of also having... probably hundreds of thousands if not millions of professional applications depend on it; it should be run like a business, because millions depend on it.

...which makes it all the weirder that security isn't any better, as in, publishing a package can be done without a review step on the npm side, for example. I find it strange that they haven't doubled down on enterprise offerings, e.g. creating hosted versions (corporate proxies), reviewed / validated / LTS / certified versions of packages, etc.

Post reply on HN