NPM Vs. Yarn: A Historical Comparison
One of the biggest draws to Javascript and Node.js is their robust library of packages. In the earliest days of Javascript, there were few to no dependencies available for installation and use. There weren’t enough developers working with the language, and even less willing to provide their code for free. The only dependency for many basic HTML apps was a browser and vanilla code. However, like anything else, as the Javascript ecosystem matured, so did its library of shared and available packages, which presented a new issue: it was tedious and finicky to manually install and store each desired package in a repository.
NPM
To provide a solution to this problem, NPM was created in 2010 to manage the use, management, and installation of packages. As the first Javascript package manager, NPM and the package library grew rapidly and in tandem, to the point that between 2012 and 2016 NPM became an almost indispensable tool for any web developer.
However, as the sheer number of dependencies available through NPM grew and grew, yet another unforeseen problem arose. The original NPM was single threaded, which means that only one installation can take place at a time. Perhaps even more damaging, NPM had no caching system, so every time a new dependency was installed every single other dependency had to be reinstalled. Early on this wasn’t such a problem as there were generally few dependencies per project, but around 2016 modern web applications relying on NPM were running into enormous installation times and bloated node_modules repositories over the course of development.
The inconvenience and poor front-end performance that resulted was a major point of contention in the opinion of NPM, and NPM developers did little to alleviate these concerns.
Yarn
Enter Yarn, which was introduced in late 2016 by developers at Facebook as the answer to NPM’s inefficiencies. Although it wasn’t bundled into Node as NPM was, Yarn still offered access to NPM’s massive library of packages. It also introduced the yarn.lock file which controlled the installation of dependencies and reduced the bloat of the node_modules folder. And lastly Yarn’s multi-thread performance and its offline mode and adjacent caching system allowed for far faster build and installation processes than was possible using NPM.
Yarn at this point had a clearly superior feature set, but as with all things it took some time to adopt. Programmers could see the advantages it provided, so gradually but steadily, Yarn started eating into NPM’s user base. However this period of transition allowed NPM time to develop competing features, which is why today it is still the most widely used package manager.
Catch Up
Caught on their heels in 2016, NPM developers realized they had to build features that would allow their product to compete in order to retain their dominance. Shortly after Yarn was introduced, NPM released shrinkwrap, an attempt at dependency locking which users found buggy and generally ineffective. After shrinkwrap’s repeated failures, NPM finally scrapped the feature and came out with package-lock.json in 2017. This was a complete copy of the yarn.lock file, but it did even the playing field significantly in terms of performance.
NPM’s next major update came in 2018 in the form of NPM 6. This release shrank the performance gap between NPM and Yarn even further, along with all new security features that were far ahead of anything Yarn was able to develop in its two year window. From this point on NPM and Yarn have been comparable products, although with wildly different paths.
Head to Head
Back in the present, it may be true that NPM and Yarn provide similar performance and many features that are nearly identical. The lock files, access to the NPM repository, ease of migration, and built in commands to update dependencies are some of the main parallels between the managers. However there are still enough differences to warrant a more thorough comparison of their features.
First, popularity in a package manager is more than a detail of vanity. The more widely used a manager is, the easier it is to share packages and create widely compatible products. In that case NPM never let go of and still clearly holds the trophy for largest user base. As the standard since its introduction, NPM dominates download numbers and uses in projects. However, looking at other metrics, at least a legitimate case can be made for Yarn. Its growth is still at a higher rate than NPM’s, which may be explained by the fact that they were the last to drastically improve performance. Furthermore Yarn’s Github page has more than double the activity of all of NPM’s Github pages combined.
Second, differences in total performance may be negligible between NPM and Yarn, but many aspects of their use are still implemented differently. Yarn needs to be installed, either as an NPM dependency itself (which Yarn developers recommend against) or through homebrew, macports, or some other installation script. Meanwhile NPM comes pre-bundled with Node making installation as simple as an initialization command in the project repository. In terms of package installation, the package-lock.json file removed most of the pitfalls of NPM’s single-threaded performance, but on occasions where several dependencies are installed at one time, Yarn is still the only manager to offer multi-threaded installations.
The third and final significant departure Yarn and NPM have from each other is in security. NPM provides a comprehensive built in security system that logs warnings whenever installing code with vulnerabilities. It also comes with the audit command, which recursively assesses a project’s dependency tree and automatically fixes whatever vulnerabilities it can. Yarn does provide checksum which can verify the security of its dependencies along with better formatted logs, but its security features are nowhere close to as fully developed as NPM’s. The good news is that NPM’s dependency library is generally fairly safe and secure, and since both managers access its packages, security is often not an issue.
The Future
Given the context of NPM and Yarn’s intertwined histories and their comparable performance at the present, there is no clear answer to which package manager should be the industry standard. Upon its introduction, NPM was a major innovation in the world of web development, yet it stagnated against advancements in technology until a competitor forced it to improve. Likewise Yarn has done little since 2016 to significantly improve their product, and while either choice is perfectly competent today, there remains the possibility that growth in the field will uncover new problems for them to deal with. It seems that necessity and competition can force innovation, so it’s always useful to keep a finger on the pulse where it looks like an adequate solution already exists, because you never know where the next big thing can come from.
