Other languages do have bundlers and JS is not the only client side target. In the Java world this is called building an uber-jar and if you want to "tree shake

Other languages do have bundlers and JS is not the only client side target. In the Java world this is called building an uber-jar and if you want to "tree shake" it you'd use ProGuard or R8. Conveniently, R8 uses the same config file syntax as ProGuard so there's a standard for defining what to keep/rename/etc. Or if compiling to native code, then GraalVM native image which deletes dead code and creates a single binary at the same time. These tools seem to work better than the JS equivalents in my experience, or at least they are a lot more stable. It's probably because they're products of companies who want to maintain stability for their users, they aren't just projects that were written, uploaded to GitHub and then eventually abandoned. ProGuard has been maintained for over two decades, R8 was written for Android and is maintained by Google, GraalVM is a 10+ year project maintained by Oracle etc. The Java dependencies situation is not so messy, I think. You've named a variety of different build tools but they all agree on where to find dependencies, how they are named, how to download them, and dependency graphs aren't quite as large or deep as they get in the JS world. Most projects use Maven or Gradle. Ant is obsolete, Bazel is really only used by Google or Google-adjacent firms and sbt is for a different language. Your ~/.m2/repository directory is a cache of every library version you ever downloaded, it's not the set of JARs used in a specific project. The biggest problems JVM world modules have are: 1. The half-completed, not really successful attempt at modular JARs which encapsulate their internals. Adoption is slow, and it's not unheard of to find popular libraries with broken module metadata. 2. If you get version conflicts the build tool has to pick one version, usually the highest. The JVM can do isolation of dependency graphs, but the integration between build/deployment tools and those APIs isn't there. Fine if that library is backwards compatible. A mess if it's not. 3. The general prevalence of 'shading' (bundling) as a way to resolve such issues. 4. The near total reliance on Maven Central as the one big server. Of course most language ecosystems have this issue, but it used to be better with many dependencies sitting on other repositories. Over time those other repos went away and now it's all just Sonatype and Central.