4 ms·
Can we just stop with these kind of kitchen sink libraries? I think substack said it best (https://github.com/substack/browserify-handbook#module-philosophy ht
by iamleppert 12y ago
Can we just stop with these kind of kitchen sink libraries?
I think substack said it best (https://github.com/substack/browserify-handbook#module-philosophy https://github.com/substack/browserify-handbook#module-philo...):
People used to think that exporting a bunch of handy utility-style things would be the main way that programmers would consume code because that is the primary way of exporting and importing code on most other platforms and indeed still persists even on npm.
However, this kitchen-sink mentality toward including a bunch of thematically-related but separable functionality into a single package appears to be an artifact for the difficulty of publishing and discovery in a pre-github, pre-npm era.
There are two other big problems with modules that try to export a bunch of functionality all in one place under the auspices of convenience: demarcation turf wars and finding which modules do what.
Packages that are grab-bags of features waste a ton of time policing boundaries about which new features belong and don't belong. There is no clear natural boundary of the problem domain in this kind of package about what the scope is, it's all somebody's smug opinion.
Node, npm, and browserify are not that. They are avowedly ala-carte, participatory, and would rather celebrate disagreement and the dizzying proliferation of new ideas and approaches than try to clamp down in the name of conformity, standards, or "best practices".
Nobody who needs to do gaussian blur ever thinks "hmm I guess I'll start checking generic mathematics, statistics, image processing, and utility libraries to see which one has gaussian blur in it. Was it stats2 or image-pack-utils or maths-extra or maybe underscore has that one?" No. None of this. Stop it. They npm search gaussian and they immediately see ndarray-gaussian-filter and it does exactly what they want and then they continue on with their actual problem instead of getting lost in the weeds of somebody's neglected grand utility fiefdom.
- tjmehta 12y agoI totally agree with this philosophy. It sounds especially great on paper. However, while in practice, adherence to the module pattern can become quite annoying for very small modules. Small modules usage throughout a project can change very quickly, because of this one may find themselves repeatedly adding a removing utility modules at a multiple times a day. Small breaks to npm install or remove small modules throughout your day can lead to a lot of wasted time (since it breaks your programming focus). Also, remembering which small module you used can be difficult (bc there may be many). I think there are pro's and con's to each strategy.. IMO I think the micro libraries are an exception to the rule, where grouping them together can be beneficial to developers.
- Tloewald 12y agoIndeed, 101 is broken up into an almost ridiculous number of tiny pieces -- the implementation of the and function is about as big as the necessary require statement. I think or() and and() (for instance) could be in the same file.
- spicyj 12y agoThat's a convincing argument, though there's also value in having a set of utilities that are maintained competently by someone you can have confidence in – I know that the functions in underscore, lodash, etc. are (at least mostly) bug-free and fast, whereas it's a hassle to evaluate the quality of every microlibrary I come across.
- tjholowaychuk 12y agoDepends on the case, for application-level development these aggregate libraries can be really handy, no one wants a stack of ~100 requires (I've seen it).
- heydenberk 12y agoThis isn't a kitchen sink library. It provides syntactical operators as functions, much like the python "operator" module in the stdlib.