3 ms·
This ignores the fact that js libraries need to be downloaded on every run. Even if there were a great general-purpose string module that included the functiona
by dcosson 11y ago
This ignores the fact that js libraries need to be downloaded on every run. Even if there were a great general-purpose string module that included the functionality, a micro-package like left-pad would be less to download if you didn't need the other stuff so I imagine some developers would still use it.
It's almost ironic really, that js has the worst standard library situation of any popular language yet it would benefit the most from having a good one since it would save everyone bandwidth and page load time.
Maybe someone can write an amazing replacement stdlib and we can all agree to include it from the same CDN so it'll be cached on every browser in the world...
EDIT: I see from other comments that lodash functions can be required individually which I hadn't thought about. But the point still stands, every function that you use in a big project that could have been in the standard library is more to download.
- nshepperd 11y agoSounds like all you need there is a compiler (people already use minifiers, right?) that would include or inline the used functions as appropriate and the cost would mainly go away? Or add in the "fetch this version from CDN" library loader code if it's a stdlib we expect to be cached and used by many js scripts.
- EvanPlaice 11y agoES6 modules, combined with a tree shaking build tool solve this issue. You can install a hige library and the output source will only include the parts you use. Unfortunately, libs that provide function chaining via dynamically extwnding a prototype can't be optimized by tree shaking. The future :: function bind operator should provide a tree shaker friendly alternative.
- nemild 11y agoYou seem to be optimizing size of download as the critical issue, when I think there are a few other optimization points that this controversy highlighted (e.g., quality of external codebase, security risk, maintainer risk, dependency management challenges). A main issue with the current system is that you're pulling in micro dependencies from a variety of different sources, instead of a few potentially highly reputable sources (fairly or not, I'd feel more comfortable with dependencies from the lodash maintainer, than from 50 different people). One solution obviously is a better standard library, but often to get there, the process is for devs to create common libraries - which over time are (partially) absorbed in language standards.