5 ms·

The reason for a centralized local cache in Java is just because Java and jar files date back to the mid 1990s. Maven to the early 2000s. Storage was expensive.

The reason for a centralized local cache in Java is just because Java and jar files date back to the mid 1990s. Maven to the early 2000s. Storage was expensive. I wrote my first Java programs on a machine that had 16mb of RAM and a couple hundred mb of disk space. Centralized caches of compiled code present all sorts of logistical issues when it comes to deployment. Java has suffered through several generations of uberjar-like designs. Python, also dating to the 90s, as a source based language tried to solve for both local and centralized trees and the result is a horrendous soup. In contrast, PHP- yet another 1990s language- had a model of just dumping files into the directory and serving them, which was comparatively simple and uniform. Node, invented in the late 2000s by a C++ and Ruby programmer, was intended to simplify all sorts of aspects of writing webservers, leveraging in particular the deployment model of PHP (all needed files in source code in the local file tree) with the superior runtime performance and scalability, including support for async, of the Javascript V8 runtime, and with the benefit of having the same language both client and server side, something that was first tried with both Java and Javascript in the late 1990s but for various reasons failed. The other major envisioned benefit to Node was that it was its own webserver, and this has led to many other innovations. That Windows still after 25 years of the NT architecture has a file system that doesn't scale is not something most tooling in the web ecosystem doesn't concern itself with. Node, like PHP, was linux first and foremost. HTH.

wging 4y ago
It's not the storage used but the repeated downloading, if I understand the complaint correctly. Avoiding the network traffic if you have an exact match should be much faster on a clean build, even if you don't care about disk space.
- MBCook 4y ago
  Right. If I have three projects using React 17.0.0, I have three copies. If I start another project with React 17.0.0 it will download another copy (and of the hundreds/thousands of dependencies) even though I may already have three copies of each. And what if I try to make a project while offline? Maven can do it if I’ve previously downloaded that package. My employer is big on Windows. All those copies of tens of thousands of files has a serious time cost. Even if dependencies were kept zipped up but not shared that would make more sense to me. Easier to deploy than individual files, smaller too.
- dec0dedab0de 4y ago
  Npm has a cache
User23 4y ago
> That Windows still after 25 years of the NT architecture has a file system that doesn't scale is not something most tooling in the web ecosystem doesn't concern itself with. This isn't exactly true. It's not so much that NTFS is slow, it's that it's not optimized for the usage patterns that Linux's FS is. That being said, it's certainly possible to have high IO performance on Windows if you know what you're doing.
- MBCook 4y ago
  Right. Creating and deleting thousands of tiny files and directories isn’t something it was designed to be fast at. But that’s exactly what NPM does.
- adgjlsfhk1 4y ago
  ntfs is straight up bad. the way you get high performance io on windows is by inventing your own file system and dumping all the data into the same file because ntfs hasn't figured out how to make your ssd slower (yet).
  - bitwize 4y ago
    Wait, you mean you don't run your system off a huge RAM disk and only periodically commit to permanent storage? Do you even know how to Windows? :)
Sankozi 4y ago
Distribution problems you mention in Java are not handled by NPM at all and are not related to how you store dependencies (in Java). Not sure why you mention it. NPM dependency resolution is neither simpler nor faster compared to Maven. You have two commands for installing dependencies: slow one (npm install) that updates package-lock based on config file developer use faster one (npm ci) is based on package-lock cache-like file that is hard to read, you cannot be sure package-lock file is correct for current config file without running npm install, different versions of NPM will create different package-lock files Both commands are slower and more buggy compared to Maven. Clearing dependency directory (node_modules) and trying again installing is a common practice when working with NPM. NPM is fast and correct only if it acts as a script runner - i.e. it is calling JS libraries (that are expected to be installed, NPM will not check that for you). I find putting dependencies inside project folder to be most stupid design decision of NPM (second one is choosing json for configuration file syntax). NPM's simplicity seems to be related only to its implementation (but somehow it did not prevent it being the most buggy cli tool I have ever used). It is basically a dependency downloader with script runner capabilities.

wging 4y ago

It's not the storage used but the repeated downloading, if I understand the complaint correctly. Avoiding the network traffic if you have an exact match should be much faster on a clean build, even if you don't care about disk space.

MBCook 4y ago
Right. If I have three projects using React 17.0.0, I have three copies. If I start another project with React 17.0.0 it will download another copy (and of the hundreds/thousands of dependencies) even though I may already have three copies of each. And what if I try to make a project while offline? Maven can do it if I’ve previously downloaded that package. My employer is big on Windows. All those copies of tens of thousands of files has a serious time cost. Even if dependencies were kept zipped up but not shared that would make more sense to me. Easier to deploy than individual files, smaller too.
dec0dedab0de 4y ago
Npm has a cache

User23 4y ago

> That Windows still after 25 years of the NT architecture has a file system that doesn't scale is not something most tooling in the web ecosystem doesn't concern itself with. This isn't exactly true. It's not so much that NTFS is slow, it's that it's not optimized for the usage patterns that Linux's FS is. That being said, it's certainly possible to have high IO performance on Windows if you know what you're doing.

MBCook 4y ago
Right. Creating and deleting thousands of tiny files and directories isn’t something it was designed to be fast at. But that’s exactly what NPM does.
adgjlsfhk1 4y ago
ntfs is straight up bad. the way you get high performance io on windows is by inventing your own file system and dumping all the data into the same file because ntfs hasn't figured out how to make your ssd slower (yet).
- bitwize 4y ago
  Wait, you mean you don't run your system off a huge RAM disk and only periodically commit to permanent storage? Do you even know how to Windows? :)

Sankozi 4y ago

Distribution problems you mention in Java are not handled by NPM at all and are not related to how you store dependencies (in Java). Not sure why you mention it. NPM dependency resolution is neither simpler nor faster compared to Maven. You have two commands for installing dependencies: slow one (npm install) that updates package-lock based on config file developer use faster one (npm ci) is based on package-lock cache-like file that is hard to read, you cannot be sure package-lock file is correct for current config file without running npm install, different versions of NPM will create different package-lock files Both commands are slower and more buggy compared to Maven. Clearing dependency directory (node_modules) and trying again installing is a common practice when working with NPM. NPM is fast and correct only if it acts as a script runner - i.e. it is calling JS libraries (that are expected to be installed, NPM will not check that for you). I find putting dependencies inside project folder to be most stupid design decision of NPM (second one is choosing json for configuration file syntax). NPM's simplicity seems to be related only to its implementation (but somehow it did not prevent it being the most buggy cli tool I have ever used). It is basically a dependency downloader with script runner capabilities.