[steven-xu]

> Bazel is designed to be optimal and has perfect knowledge of the state of the world, yet it’s too slow for quick operations.

This is one of the biggest challenges where Bazel falls short of non-Bazel tooling for us in the Web development/Node.js world. The Node ecosystem has characteristics that push Bazel scaling (node_modules is 100k+ files and 1GB+), and Bazel's insistence on getting builds correct/reproducible is in a way its own enemy. Bazel needs to set up 100s of thousands of file watchers to be correct, but the Node.js ecosystem's "let's just assume that node_modules hasn't changed" is good enough most of the time. For us, many non-Bazel inner devloop steps inflate from <5s to >60s after Bazel overhead, even after significant infra tuning.

[aliasxneo]

It's not unique to Bazel. Nix also struggles with Node.js. I'm not too fond of either solution, but to me, the problem lies in the Node ecosystem, and it seems unlikely a "language-agnostic" tool will ever be able to crack that nut.

[GauntletWizard]

Node also struggles with Node.js, and that's including its shortcuts that kill reproducibility. A node.js sync from an empty cache is by far the longest part of any build process I maintain. It's still a long step with a full cache and without doing anything.

[malkia]

I always wondered, why `node_modules` growing so big (in terms of file count) was ever ok. Apart from bazel, having that many files sucks anyway.