@matigo your care is good, but your concerns about the alternatives don’t seem much of an issue ime.
[edit: i made the mistake of thinking of frontend code here, but i think you might have meant backend?] unused code is scarcely an issue in production builds. common practice is to use a bundler such as webpack, parcel, or rollup to strip it out for prod. (before that latest generation of bundlers, google’s closure compiler served a similar purpose, and was picked up by clojurejs for that reason.)
i’m more concerned about:
- drowning in complexity
- poor module design not letting me fix a problem without forking
- latent bugs & attack surface
it requires the same consideration as pulling in a module into a C/++ project. and at least closed-source blobs are way less common, so i’m not stuck reversing a library to debug an issue or infer the docs they failed to ship.
edit: on second reading, a lot of plain node projects are not compiled for distribution, and i mixed up frontend/backend. it’s interesting - backend js tends to treat modules more like dynamic libraries, while frontend js does tend to link and cross-module optimize the heck out of everything.
the motivation of course is that the download and install cost serverside is not a major concern vs the per-browser data transfer cost of frontend code.
/@sumudu @AndrewG