4 ms·
It depends how you define bloat. If you define bloat strictly as number of dependencies, then sure, the Node ecosystem encourages more "bloat" than any other ma
by benesch 11y ago
It depends how you define bloat. If you define bloat strictly as number of dependencies, then sure, the Node ecosystem encourages more "bloat" than any other mainstream ecosystem.
But if you define bloat as "inclusion of features I'm not using," the Node ecosystem is lean and mean. If I only need 15 of the 250 functions that Lodash provides, I can include each of those 15 functions as an individual package. Yes, it increases disk space, because each dependency ships a package.json and a README and subdependencies aren't shared, but disk space is cheap. Decreasing the surface area of my library dependencies is worth it for my development happiness.
I think the criticism you want is "ultra-modular." You can make an argument that Node's proliferation of tiny, one-function packages is a maintenance burden and causes discoverability problems. Personally, I disagree: any effort to move towards a world where you never have to write a line of code someone else already has is well worth it. And from an end-user perspective, it shouldn't matter at all. `npm install` on average takes no longer than `gem install` for me, despite NPM pulling in orders of magnitude more packages.
(Python might be bloated; have you ever looked at the complete stdlib? There are some horrifying pieces: urllib2, email, turtle (?!).)
P.S. Check out libsass [0], a re-implementation of Sass in C with [probably] bindings to your favorite programming language.
[0]: https://github.com/sass/libsass https://github.com/sass/libsass
- Nullabillity 11y agoThen again, not being noticeably slower than gem install doesn't mean a lot.