Brief History of Yarn

Yarn is a package manager for JavaScript, created by Facebook as an alternative to NPM. It was developed in 2016 in response to issues with NPM, particularly frustrations with NPM's product management and development prioritization. Yarn differed in two major ways:

It was faster, offering obvious benefits.
It allowed saving a .lock file in the repository, essential for portability with the increasing complexity of the JS ecosystem.

By 2016, a competitive tool to NPM emerged with two killer features. NPM took notice as users began to shift and changed its priorities. In 2017, NPM introduced its own .lock feature and continued to evolve, influenced by Yarn's innovations. By 2020, both tools had largely equalized.

Recap:

2016: Yarn emerged as a faster, more portable alternative to NPM.
2017: NPM caught up in portability.
2020: NPM matched other features.

Current Perspective:

There's a global shift away from Yarn, with most new projects reverting to NPM. Online, there's significant criticism of Yarn, surprisingly due to its very creation. The main criticism is that Facebook didn't collaborate to advance NPM itself but instead created another solution, following the then-popular trend of creating 'Yet Another Anything.'

Should Yarn Have Been Created?

In hindsight, everything seems simple. Facebook's primary needs were to introduce a .lock file and speed up the tool. Development is costly, and even coffee breaks during builds add up. The argument is solid up to the point where it suggests that Facebook should have contributed these improvements directly to the NPM repository.

But what about the NPM product owner at the time? They might have argued that speed wasn't a priority, especially at the expense of compromises. And the .lock file? If specific versions were needed, there were ways to set them. Minor updates shouldn't cause issues, and deployments were infrequent, so a pre-build check was deemed sufficient.

This stance didn't change until the creation of an alternative. Only when Yarn emerged as a competitor did NPM begin to respond.

So, is competition necessary?

Yes, it's a key takeaway. Competition is necessary. It allows users to vote with their feet, not just a thumb on a roadmap tool.

Is that the only conclusion?

Not entirely. Being against the division of development resources in OSS is a valid perspective, shared by an increasing number of tech celebrities. Consider debates like JavaScript vs TypeScript, Java vs Kotlin, CSS vs Tailwind. The argument is simple: it's a waste of time. Alternatives to dominant technologies might enrich them, but they only slightly steer their development.

When speaking with developers, for instance, during interviews, I respect both approaches: sticking to the foundational technology and actively improving it, and seeking a perfect match for a specific problem. I'm not a fan of hype waves and consider them a red flag.

Is there an alternative without the need for competitive pressure?

It's hard to say. It depends on the value you place on speed. Democratic processes in OSS inherently can't be quick. Finding consensus in even slightly diverse communities is challenging. To give credit where due, a functional democratic community example is the development of Golang.

https://github.com/orgs/golang/projects/17

They have a clear foundation and philosophy for the language. Refer to: why and how it was created. And they have a good framework for advancing proposals, from quickly described ideas to polished design documents and implementation. Speed? Consensus on adding generics took 10 years. Was it worth it? Yes. Could a Yet Another Go fork from Facebook have sped it up? Yes. But that would have been another division of development resources.