111–120 of 253 posts
My 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.
I think people forget that, when you’re copying the same images to dozens and dozens of boxes, any improvement starts to add up to real numbers.
Earlier quoted context omitted.
> This is a solid example of how things change at scale. 5% is 5% at any scale.
5% of newly published packages, with a potentially serious degradation to package publish times for those who have to do that step. Given his numbers, let's say he saves 100Tb of bandwidth over a year. At AWS egress pricing... that's $5,000 total saved. And arguably - NPM is getting at least some of that savings by adding CPU costs to publishers at package time. Feels like... not enough to warrant a risky ecosystem c…
Even that's addressable though if there's motivation, since something like transcoding server side during publication just for popular packages would probably get 80% of the benefit with no client-side increase in publication time.
Usually people require more than 5% to make a big change
Earlier quoted context omitted.
I felt the same. The proposal wasn't rejected! Also, performance gains go beyond user stories - e.g. they reduce infra costs and environmental impact - so I think the main concerns of the maintainers could have been addressed.
> The proposal wasn't rejected! They soft-rejected by requiring more validation than was reasonable. I see this all the time. "But did you consider ? Please go and run more tests." It's pretty clear that the people making the decision didn't actually care about the bandwidth savings, otherwise they would have put the work in themselves to do this, e.g. by requiring Zopfli for popular packages. I doubt Microsoft cares…
That's the market price though, for Microsoft its a tiny fraction of that.
> Zopfli is written in C, which presents challenges. Unless it was added to Node core, the CLI would need to (1) rewrite Zopfli in JS, possibly impacting performance (2) rely on a native module, impacting reliability (3) rely on a WebAssembly module. All of these options add complexity.
Wow! Who's going to tell them that V8 is written in C++? :)
Earlier quoted context omitted.
That’s an argument against making any change to the packaging system ever. “It might break something somewhere” isn’t an argument, it’s a paralysis against change. Improving the edge locality of delivery of npm packages could speed up npm installs. But speeding up npm installs might cause the CI system which is reliant on it for concurrency issues to have a race condition. Does that mean that npm can’t ever make it f…
It is an argument. An age old argument: "If it ain't broke, don't fix it."
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…
Earlier quoted context omitted.
> This is a solid example of how things change at scale. 5% is 5% at any scale.
5% of newly published packages, with a potentially serious degradation to package publish times for those who have to do that step. Given his numbers, let's say he saves 100Tb of bandwidth over a year. At AWS egress pricing... that's $5,000 total saved. And arguably - NPM is getting at least some of that savings by adding CPU costs to publishers at package time. Feels like... not enough to warrant a risky ecosystem c…
NPM uses at least 5 petabytes per week. 5% of that is 250 terabytes.
So $15,000 a week, or $780,000 a year in savings could’ve been gained.