[gentleman11]

npm is a bit nuts on its own. I started learning react this year and the course I'm taking had me install that create react app module or similar. It dragged in 1700 dependencies, and the folder for a hello world app was almost 90mb iirc. How can you possibly pretend you have any control over your app or it’s security in that situation?

[TechBro8615]

The reason it’s so big is because it’s your build chain. I’ve always found this criticism of JS annoying – you’ve also got to pull in a few hundred MB of tooling for C++, Java, or Rust — it’s just that in the JS case, the “compiler” is usually per project.

[jeroenhd]

In my experience, Java and Rust have the exact same problem. The nature of the dependencies is different, though; in Rust or Java, you'll have dependencies that handle a protocol, set up something like TLS, manage state, that kind of thing. In Javascript, you'll have a single dependency that provides a single function that does a recursive file search, or a dependency like is-number that checks if a variable is a number.

Javascript seems to prefer millions of tiny dependencies of thousands of larger libraries, which is a choice that can be defended. The difference is not necessarily one in lines of code or binary size, but one in amount of vendors trusted. Many libraries also handle trivial code that (in my opinion) should be part of the programming language or basic developer knowledge already. The is-something packages that fill Javascript dependency trees to the brim can only be considered as failings of the language in my opinion.

As a developer, I trust parties like webpack, gulp, and Facebook, but I haven't heard about jonschlinkert (nothing against him, just a random name I picked) and I don't know who maintains is-number, is-path-cw, is-path-in-cwd, is-path-inside or path-is-inside and how reliable they are. All of these dependencies seem like excellent methods in a library, but they all could've been part of a single dependency no more than 60 lines of code in length. Many NPM packages feel less like libraries and more like automated StackOverflow answers. Adding a vendor to your supply chain for just 40 lines of open source code is just inefficient; why risk trusting yet another vendor to not inject malware in the future like this?

The Java world has some popular names like Apache, Google and Jetbrains that maintain large libraries so it's easy to build a chain of trust. Rust is moving the Javascript way, with hundreds of megabytes of dependencies from thousands of individual repositories, but at least most of its packages add something nontrivial.

C++ doesn't have a package manager, at least not in the same way other languages do. C++ libraries usually come from very specific toolkits or single sources (like Linux package managers). There's tons of packages for C++ development, but all of them are kept up to date by a single organisation on my machine.

[username90]

Other libraries are usually self contained though, unlike JS libraries which contains dependencies and then those dependencies has dependencies etc. Probably has to do with JS lacking a standard library so it is a pain to do anything without including dependencies.

[hsbauauvhabzb]

That’s hardly true. Some standard libs are smaller, but in most other languages I can think of there isn’t the complete dependency hell. I want to install one package, the 50 dependencies or their ancestors create an audit he’ll (is the package secure, so I trust the developer to not inject malware, abandon the package, or add more dependencies), etc.

[TechBro8615]

My point was that if you're comparing JS dependencies to other languages, you need to include their compilers too, since e.g. TypeScript projects depend on `tsc`. If you include the size of C/C++/Rust/Java/etc. compilers, I'm sure you'll find 50mb+ of dependencies. You're right that it's self-contained though (to be fair, so is `tsc` – most projects could shed a lot of dependencies by abandoning Babel in favor of `tsc` or esbuild).

[hsbauauvhabzb]

Sure but gcc, clang and python have had a substantial amount of review. There’s no assurance that similar occurs in the non ecosystem.

[ratww]

Yeah, that’s the biggest issue, IMO.

Even a simple app with only React as a production requirement will have dozens of issues a month.

There are some packages that don’t have as many dependencies such as Typescript or Prettier, but that’s not enough, since the most popular bundlers have hundreds of of dependencies.

No matter how careful you are, you get flooded by security issues.

[bhl]

Just curious, have you tried vite with react? It uses esbuild, which might result in a heavier dependency folder, but I also wonder if getting rid of webpack removes a lot of the CRA dependencies.