I think substack said it best (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.
1. Lo-Dash and Underscore overlap with ES5 for a few reasons. First, it allows them to support environments where ES5 functions aren't available. Those are becoming less common but still exist. But the other big reason they overlap is that Underscore and Lo-Dash both outperform native functional methods by a significant amount. Unintuitive but true, see my comparison from a few weeks ago [0]
2. It's worth thinking about who this library is for. The support for common JS and highly modular nature of the library make it seem like it is focused on Node first. But the value in a smaller library becomes much more clear in the browser where page weight matters.
These aren't meant as criticisms, it's good to see new ideas. But it's worth thinking about what niche you're filling when you develop a library like this.
[0]: http://benmccormick.org/2014/11/12/underscore-vs-lodash/
I use Webpack (similar to Browserify, but I understand Webpack's more powerful), and I can't imagine starting a new JS project without it.
A good read on the subject of performance and native method replacements:
I was thinking `throw new Error('You're doing it wrong');` :-P
You could also make /dist/index.min.js.
and(true, false); // false
and(true, true); // true
I'm not convinced that there's a real need for that. Anyone else have a good use for something like that? Looks like it doesn't even take more than two arguments
var Promise = require('bluebird');
var fs = Promise.promisifyAll(require('fs'));
var and = require('101/and');
var paths = [...];
Promise.map(paths, fs.existsAsync).reduce(and)
.then(function(allExist) {
if (allExist) console.log('all paths exist');
}); var and = require("101/and"),
apply = require("101/apply");
var o = require("101");
o.apply(/*...*/);
o.and(/*...*/);
I'm confused, the majority of this library seems to be wrapper functions for built-in vanilla js operations.
For example, `exists` function can not really help with undeclared variables. At the end of day you have to use `typeof something !== 'undefined'`. I don't really understand what this library is trying to solve