Ripping Yarns

Today marked the release of Yarn, a package manager that’s backwards compatible with npm. It is quite fast, written by heavyweights in the JavaScript community.

If you look at it through the lens of a typical JavaScript engineer, you think: Wow! Now my installation of packages and management of those packages is better (and it is!). This is great! it shaves minutes of time off of installing a large package file.

I can’t look at it that way. Yarn is a hostile takeover that is framed as a quality of life improvement. That’s fine, I suppose. But I ask you this; What about Bower?

Bower is a “don’t use” system, right now. You shouldn’t use it with new projects. Everything should just be NPM. NPM, as a package manager, has been around for basically as long as Node has, and for better or worse, has been fine. Will NPM suffer the same fate now that Yarn is being adopted as the ‘new good version’ of NPM?

You didn’t need to peg a dependency to a single version, so if a module you’re using uses version foo of a dependency, only that dependency will need to use it, and you can use foo 2.0 in your code. No problem.

Sure, NPM is slow. the npm3 release is a complete sea-change to how dependencies work, with the removal of peer-dependencies. This is the pain of progress, I guess.

Yarn comes into the picture as a savior of two things: it’s really really really fast, and it’s lock based. It’s heavily cached. It lets you install from either registry, Bower or npm. Backwards compatible with npm.

It’s important right now to stress that before I get into the meat of this argument, that you understand I will absolutely use yarn and I will probably forget its presence after a few days, and most of the engineering ecosystem writing javascript today will too. I just don’t like that this is where we’re at, as an ecosystem.

Let me explain. You have two different kinds of apples. One apple has a skin, some flesh, seeds, and a stem. One is green, slightly smaller than the other, and is somewhat sour. The other apple is big, muscular, red, and slightly larger than the green one. Which one do you choose?

With Yarn, I feel like the JavaScript community is going to go with the smaller green apple, because it’s slightly faster to eat. What about all the other Red apples that are just as nutritious and delicious, but take a bit longer to grow and a bit longer to eat?

Breaking that analogy down further, in order to prepare each apple, with the red apple you just grab it and take a chomp, chew, and so on. With the green apple, though, you’ll need to have a file that says what parts of the apple have been eaten, and ensure that you properly chop it up with a knife or specific unitasker before you can eat a slice of it.

If you end up eating those slices in the wrong order, you can never get to the point where you’ve consumed the entire apple. You’ll have to throw it all out and grab a fresh apple.

This is what ‘lock-by-default’ means. Any developer who has had to work through the dumpster fire of reconciling rubygems via gem, which was supplanted by bundle have had to deal with at some point. It’s just easier to blow everything away than to try to resolve the issues. Delete the lockfile and move on.

Yarn states that this is a Good Thing, because it makes explicit dependency upgrades better. I’m sure they’ve got substantive evidence that makes a strong case for you to say “Yarn is actually pretty cool”, give a thumbs up emoji, and carry on with your day. They do.

That’s ultimately fine; To say otherwise is to throw ignorance I have about the problem into the fire, and I’m not trying to be hyper critical of Yarn itself, or the really smart people who thought this was a real need.

What I’m disappointed over is that this is where time is still being spent in the ecosystem. I appreciate that this seemed like a problem worth solving. But — Why not work with the NPM team on a plan for a complete reboot of npm for version 4, one that incorporates all of the nice things that Yarn provides?

I don’t want to single out Ben — He was just responding to my constant bitching on twitter. It IS telling, however, that it didn’t work out from both ends.

Think about that for a minute. Facebook and Google didn’t want to collaborate on fixing a platform level library for one of the most popular languages out there?

To me, this is the largest glaring problem with the ecosystem that engineers find themselves in lately. There’s too much competition over the important things, that nothing seems to make a ton of progress in a single direction.

You also end up having situations where developers are discouraged about making modifications to existing mature libraries that may be showing some signs of weakness.

Yarn should probably replace npm. And while most of the community thinks and have responded that “if it just makes npm faster, I don’t care”.

That’s the wrong attitude. Here’s hoping that the next version of npm and the Yarn team can find a way to work together, for all of our sakes. There are 398 contributors to npm at the time of publication, and 22 contributors to yarn.

Hopefully, and I really am hopeful, that those two teams can come together and build a great thing, rather than building two good things.

Therein lies the real issue with “JavaScript Fatigue”, to me. I’m tired of writing and comparing libraries. I want to focus on the language itself and what it can provide me, much in the same way Go, C++, Python, Ruby, and other languages with a large standard library do.