Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My failed attempt to shrink all NPM packages by 5%

evanhahn.com

Post reply on HN
Print view View original

31–40 of 253 posts

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

#31

Post by sd9 »

jerf wrote: post #29
sd9 wrote: post #3

The final pro/cons list: https://github.com/npm/rfcs/pull/595#issuecomment-1200480148 I don't find the cons all that compelling to be honest, or at least I think they warrant further discussion to see if there are workarounds (e.g. a choice of compression scheme for a library like typescript, if they would prefer faster publishes). It would have been interesting to see what eventually played out if the author hadn't…

"I don't find the cons all that compelling to be honest" This is a solid example of how things change at scale. Concerns I wouldn't even think about for my personal website become things I need to think about for the download site being hit by 50,000 of my customers become big deals when operating at the scale of npm. You'll find those arguments the pointless nitpicking of entrenched interests who just don't want to…

I agree with everything you said, but it doesn’t contradict my point

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

#32

Post by sd9 »

macspoofing wrote: post #24
sd9 wrote: post #3

The final pro/cons list: https://github.com/npm/rfcs/pull/595#issuecomment-1200480148 I don't find the cons all that compelling to be honest, or at least I think they warrant further discussion to see if there are workarounds (e.g. a choice of compression scheme for a library like typescript, if they would prefer faster publishes). It would have been interesting to see what eventually played out if the author hadn't…

> I don't find the cons all that compelling to be honest I found it reasonable. The 5% improvement was balanced against the cons of increased cli complexity, lack of native JS zopfli implementation, and slower compression .. and 5% just wasn't worth it at the moment - and I agree. >or at least I think they warrant further discussion I think that was the final statement.

Yes, but there’s a difference between “this warrants further discussion” and “this warrants further discussion and I’m closing the RFC”. The latter all but guarantees that no further discussion will take place.

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

#34

Post by jerf »

sd9 wrote: post #31
jerf wrote: post #29

Earlier quoted context omitted.

"I don't find the cons all that compelling to be honest" This is a solid example of how things change at scale. Concerns I wouldn't even think about for my personal website become things I need to think about for the download site being hit by 50,000 of my customers become big deals when operating at the scale of npm. You'll find those arguments the pointless nitpicking of entrenched interests who just don't want to…

I agree with everything you said, but it doesn’t contradict my point

I'm saying you probably don't find them compelling because from your point of view, the problems don't look important to you. They don't from my point of view either. But my point of view is the wrong point of view. From their point of view this would be plenty to make me think twice and several times over past that from changing something so deeply fundamental to the system for what is a benefit that nobody who is actually paying the price for the package size seems to be particularly enthusiastic about. If the people paying the bandwidth bill aren't even that excited about a 5% reduction, then the cost/benefits analysis tips over into essentially "zero benefit, non-zero cost", and that's not very compelling.

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

#37

Post by soared »

tyre wrote: post #23
bluGill wrote: post #18

Earlier quoted context omitted.

50% size savings isn't important to the people who pay for it. They pay at most pennies for 100% savings (that is somehow all the functionality in zero bytes - not worth anything to those paying the bills)

Size savings translates to latency improvements which directly affects conversion rates. Smaller size isn’t about reducing costs but increased revenue. People care.

Agreed - often a CTO of an ecom site is very very focused on site speed and has it as their #1 priority since it directly increases revenue.

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

#38

Post by inglor_cz »

hartator wrote: post #22

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

As the author himself said, just React was downloaded half a billion times; that is a lot of saved bandwidth on both sides, but especially so for the server.

Maybe it would make sense to only apply this improvement in images that are a) either very big or b) get downloaded at least million times each year or so. That would cover most of the savings while leaving most packages and developers out of it.

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

#39

Post by Alifatisk »

cedws wrote: post #25

Last I checked npm packages were full of garbage including non-source code. There's no reason for node_modules to be as big as it usually is, text compresses extremely well. It's just general sloppiness endemic to the JavaScript ecosystem.

At least, switch to pnpm minimize the bloat

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

#40

Post by bonzini »

Levitating wrote: post #30
stabbles wrote: post #17

Earlier quoted context omitted.

The main downside though, it's impressively slow. Comparing to gzip isn't really worth it. Combine pigz (threaded) with zlib-ng (simd) and you get decent performance. pigz is used in `docker push`. For example, gzipping llvm.tar (624MB) takes less than a second for me: $ time /home/harmen/spack/opt/spack/linux-ubuntu24.04-zen2/gcc-13.2.0/pigz-2.8-5ptdjrmudifhjvhb757ym2bzvgtcsoqc/bin/pigz -k hello.tar real 0m0.779s us…

> 2700x slower That is impressively slow. In my opinion even the 28x decrease in performance mentioned would be a no-go. Sure the package saves a few bytes but I don't need my entire pc to grind to a halt every time I publish a package. Besides, storage is cheap but CPU power draw is not. Imagine the additional CO2 that would have to be produced if this RFC was merged. > 2 gigabytes of bandwidth per year across all i…

2 GB for the author's package which is neither extremely common nor large; it would be 2 TB/year just for react core.
Post reply on HN