Package Manager Showdown: Yarn and NPM on a VPS

I've worked pretty hard to stay out the whole JS package manager debate. NPM's always done what I needed. Prior to yesterday evening, I had no baseline for comparison. Sure, like everyone else, I've read articles that point out how slow NPM is in comparison to Yarn. I tend to switch tabs/windows/whatever the second I forget what I was doing (i.e. every five minutes), so I don't often wait on NPM. Yarn's API also apparently comes from a totally different methodology. I've grown used to the madness surrounding NPM's method, so I've honestly had no reason to change.

Note

I'm still trying to figure out how to properly build content for AMP. I recorded a few asciicasts for this post and haven't yet figured out how to load and scale them well with a bunch of external stuff. For now, you'll have to load them externally. Sorry about that. While you're there, you might consider donating because asciinema is hella rad.

Background

Digital Ocean

The one thing that I actually require from my package managers is that they have to work in my environments. In production mode at work, that's almost never an issue. Companies understand the need for good hardware to match traffic. In production mode at home, I'm pretty cheap. I don't maintain apps with massive hardware needs because a) that's expensive and b) I don't ever have good ideas. I've gotten away with the penultimate Digital Ocean Standard Droplet for years and I have the traffic to prove it.

Ghost

I use Ghost as a blogging platform. It runs rather well on basic droplets. It's a well-constructed JS app, so it's not massively bloated. At the same time, I'm not running an enterprise server and my traffic is so small Ghost doesn't ever get a chance to run out of memory. MySQL is typically using at least twice as many resources as Ghost, which is probably a good thing because it's only running for Ghost.

Analysis

I can honestly say I've never seen npm kill an installation script. After running it again a few times to make sure, I hit Google. It turns out that this is a fairly common Digital Ocean issue. That thread suggests creating a swap file to increase memory. On an HDD, I'd do that in a heartbeat. On an SSD, that's an invitation to never see my data again. Of course Digital Ocean suggests beefing up the droplet, because they need to make money. I get it.

Neither solution makes any sense, though. All I wanted to do was install a list of remote dependencies properly built for my system. I rarely run that command. What am I supposed to do, temporarily bulk up for a single command? That's ridiculous.

Memory Usage

To make sure I wasn't making this up, I ran the installation beside htop to track everything.

Yarn

After a bit more Googling, I quickly learned that's there no way to, say, install dependencies one-by-one via NPM unless I wanted to call them one-by-one. My hopes for Yarn actually working were pretty low following NPM's spectacular performance. At least installing Yarn was quick and easy.

Analysis

Memory Usage

Watch Yarn not get killed. Also, it doesn't seem to consume everything in reach. Dunno why; don't care; it works.

Side-By-Side

I actually recorded this first because I couldn't believe they were that dissimilar. If you watched the memory consumption above, there's nothing here you haven't seen.

Verdict

I'm moving to Yarn this week. Not only did it actually work in my environment, it worked much faster than NPM was killed. If you're always running on high-end hardware with lots of resources (e.g. your servers are running Google Chrome), NPM will probably do the job. If you're not made of money, Yarn's a better bet.