Usually people require more than 5% to make a big change
My failed attempt to shrink all NPM packages by 5%
11–20 of 253 posts
Re: My failed attempt to shrink all NPM packages by 5%
#12Props to anyone who tries to make the world a better place.
Its not always obvious who has the most important use cases. In the case of NPM they are prioritizing the user experience of module authors. I totally see how this change would be great for module consumers, yet create potentially massive inconvenience for module authors.
Interesting write-up
Re: My failed attempt to shrink all NPM packages by 5%
#13My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl
Working approach, but in the end I abandoned the project - I doubt people care about such js size savings.
Re: My failed attempt to shrink all NPM packages by 5%
#14I wonder if it would make more sense to pursue Brotli at this point, Node has had it built-in since 10.x so it should be pretty ubiquitous by now. It would require an update to NPM itself though.
Re: My failed attempt to shrink all NPM packages by 5%
#15It only doesn't apply to existing versions of existing packages. Newer releases would apply Zopfli, so over time likely the majority of actively used/maintained packages would be recompressed.
Re: My failed attempt to shrink all NPM packages by 5%
#16My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl Working approach, but in the end I abandoned the project - I doubt people care about such js size savings.
Wdym?? 50% is a big deal
Re: My failed attempt to shrink all NPM packages by 5%
#17One thing that's excellent about zopfli (apart from being gzip compatible) is how easy it is to bootstrap: git clone https://github.com/google/zopfli.git cc -O2 zopfli/src/zopfli/*.c -lm It just requires a C compiler and linker.
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
user 0m11.126s
sys 0m0.460s
It is almost 2700x slower than the state of the art for just 6.8% bytes saved.
Re: My failed attempt to shrink all NPM packages by 5%
#18My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl Working approach, but in the end I abandoned the project - I doubt people care about such js size savings.
Wdym?? 50% is a big deal
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)
Re: My failed attempt to shrink all NPM packages by 5%
#19Nice write up!
> When it was finally my turn, I stammered.
> Watching it back, I cringe a bit. I was wordy, unclear, and unconvincing.
> You can watch my mumbling in the recording
I watched this, and the author was articulate and presented well. The author is too harsh!
Good job for trying to push the boundaries.
Re: My failed attempt to shrink all NPM packages by 5%
#20Props to anyone who tries to make the world a better place. Its not always obvious who has the most important use cases. In the case of NPM they are prioritizing the user experience of module authors. I totally see how this change would be great for module consumers, yet create potentially massive inconvenience for module authors. Interesting write-up
I think "massive" is overstating it. I don't think deploying a new version of a package is something that happens many times a day, so it wouldn't be a constant pain point.
Also, since this is a case of having something compressed once and decompressed potentially thousands of times, it seems like the perfect tool for the job.