Investigating npm3 performance | Hacker News Reader

Investigating npm3 performance

github.com

76 pointsbreck10 comments

They should rewrite it in node: Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop scalable systems.

This only reinforces the idea I have that NPM is the absolute worst package manager ever and I wish it would die and people would start using one that works (or building one that works)

A huge regression like that (x3 slower) is not something that should happen from a "mature" project that relases its v3. It's simply inacceptable and it clearly demonstrates that the team behind NPM is incompetent.

It's harsh to say but I tend to agree. Most of npm employees are more active in tweeting and commenting about social justice than doing their work.

Last night I was watching South Park and I thought PC principal is looking like IZS!!

This is my impression too. Half the people at npm seem more focused on social justice than making npm a better package manager.

I have long-standing gripes with design decisions taken in npm too, but I don't think its quality as a package manager is affected one way or the other by its contributors tweeting in a way you appear to dislike.

It's not a matter of incompetence. It is a known (predicted, even?) consequence of the change of their algorithm to support dependency trees that are nested as flatly as possible.

And if that methodology is so inacceptable, just continue to use npm 2. The last release on GitHub was less than 24 hours ago, and until v5 Node still shipped with npm 2.

First of all, npm 2's infinite nesting of dependency was a terrible design from the beginning. It was always broken (This is why on our windows build servers we need to do all sorts of stupid workaround to make npm work). There is no other decent package manager that nests dependencies within dependencies like that, every other package manager out there has a flat structure with packages and their version, so 2 versions of a same package can co-exist with no issues.

By fixing this huge flaw in their design, I thought there would be an increase in performance! In the end, they made it even worse. It makes no sense that fixing their flawed design would result in a 3x worse performance for doing the same task.

NPM 2 was and is not broken. There are ~200,000 packages on the NPM registry, and ~2,700,000,00 downloads in the last month. In the past four years it has done wonderful things for node.js and javascript development in general. The nested dependency tree worked great on *nix systems. Was the max path on Windows annoying? Of course it was. But stop pretending like it completely prevented you from accomplishing anything. And if you were deploying to a Windows server why did you pick an ecosystem and package manager that has always made it clear that Windows is a second class citizen? There are always trade offs.

Now NPM 3 has worked around the utterly idiotic max path on Windows at the cost of slower installs. That's also annoying. It's also temporary. Just wait a little, and keep using NPM 2 if speed is your top concern.

If Paul Irish is endorsing your analysis work, you know you're on a pretty good track.

All this just to say "requests are made one after the other now, and that's slow".. seems pretty useless

Reply on news.ycombinator.com