There were times when we had only npm but it had so many issues with resolving dependencies and caching that another tool has born (yarn). Usually it was using local cache to resolve dependencies and it was crucial for example while running CI jobs which are almost always ran in same environment and high bandwidth is costly as you pay for data in cloud services. That means in old npm versions when you ran npm install and you had lets in deps

First note

Please understand that yarn was built on the top of npm packages and https://www.npmjs.com/ that means they are both using NPM registry for resolving packages. so if you run npm install lodash@1.0.0. or yarn add lodash@1.0.0. you will get very same result

Incremental install

react@16.0.0

On every new build both dependencies were again downloaded from internet. Yarn uses yarn.lock underneath and it is comparing your package.json file with yarn.lock and determines which packages needs to be fetched additionally to only incrementally install new dependencies

Multithreading

yarn offers parallel installation of packages which are not dependent in threads. It can lower installation time to 1/10 of time from npm install

Version locking

As said before yarn generates yarn.lock after each installation which persists ALL versions of installed packages (as you probably know a package can have dependencies and a dependency can also have its own dependencies) so it can build up infinite tree of dependencies which can lead to very bad conflicts. Let's imagine this scenario

 - lodash^1 - super_module@0.0.1 - - lodash@1.0.0 - another_module@0.0.01 - - lodash@1.x.x

Imagine scenario when maintainer of another_module decides to bump lodash to breaking changes version 1.2.0 what can happen is that npm in old days could fetch 2 different instances of same library, and 2 different version which could lead to extremely weird behavior. Because as you don't have exact lock in your module (you accept any semver version ^1.x.x and ^2.x.x so that means both sub modules would satisfy your requirements but fetch different version. Yarn will lock your yarn.lock AT THE TIME OF AN ADDING new package to the project, that means when other developers on your project will checkout the project he will also have same yarn.lock and yarn will ultimately "mimic" the state of package how they were installed when you committed yarn.lock on other hands NPM just looks to the semver satisfaction and can fetch 2 different version for 2 developers (assuming that in time packages are upgrading)

Final note

There has been a lot of work from npm guys as they released npm@5 and I think all statements are now just reasons WHY yarn was created and which problems it was solving at the time, but I think at current date, it is no big difference between those 2 nowadays