3 ms·
The bigger issue is less about weight (most of that doesn't end up in the final bundle anyway) and more about the fact that each of those dependencies is a poin
by _bxg1 8y ago
The bigger issue is less about weight (most of that doesn't end up in the final bundle anyway) and more about the fact that each of those dependencies is a point of possible a) breakage and b) security compromise. The latter in particular has been a rising issue with NPM's micro-packages trend.
- arvinsim 8y agoI don't know how that problems is going away. Javascript doesn't have a great standard library and it's hard to impose restrictions on which packages/features/functionalities should be the "defacto" ones.
- _bxg1 8y agoThe strength of JavaScript is also the problem: it's really easy to create and distribute really flexible and dynamic code. This encourages a massive, vibrant ecosystem of packages which are extremely modular and flexible, and often tiny. So you end up building sandcastles out of thousands of grains of sand instead of LEGO houses. What we probably need to do is walk that back a bit at a cultural level, and make our libraries just a bit more cohesive and self-contained. There are a few libraries like Lodash and Ramada that aim to be general-purpose toolkits, and Vue and Angular are good examples of reactive libraries that come with their own state management, plus some other stuff. Of course, the latter probably (I'm not actually positive) carry their own big lists of npm dependencies.
- _bxg1 8y agoAnd for a tooling example, VSCode is basically a much more cohesive and holistically-designed version of Atom.