This is a nice start towards something that might be useful. A few thoughts about stating that "101 will be maintained to minimize overlap with vanilla JS." though:
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.
Love your well thought out feedback.
1) IMO ES5 is highly available now and when it isn't you can use shims.
2) Will definitely add other module systems on request. Currently works in the browser with browserify.
There's another benefit to including map/reduce/filter in Lo-Dash and Underscore, and that is chaining. Were these methods removed in favor of native methods, _.chain would be much less useful.
var and = require("101/and"),
apply = require("101/apply");
versus something like
var o = require("101");
o.apply(/*...*/);
o.and(/*...*/);
I can see the first one works well if you're planning to use a couple of those functions at a time. If you end up using 4-5 of them in the same module it could get a bit much.
It's a great project to teach yourself something but I don't really see why people might want to use this over lodash/underscore?
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
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.
That'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.
Depends 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).
I 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.
How would I use a "functional version of ||", or a "functional of &&"? I am not familiar with functional programing but maybe a short example of .or and .and would enlighten me a bit?
Was waiting for someone to say this. Checkout the examples - duplication is for functional usage only.
Util methods are written to work well with JS internals like Array methods (eg. map).
I should probably make this point more clear in the docs... Thanks!
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
Providing an function version of `&&` let's you use that function in more FP (functional programming) contexts, e.g. a data transform that does multiple map/apply/reduce transforms to a data set.
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');
});
Add new String(...) and new Boolean(...) to the is-(boolean|object|string) test cases for surprising fun, OP, then check out Object.prototype.toString.call(...).
[+] [-] ben336|11 years ago|reply
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/
[+] [-] tjmehta|11 years ago|reply
[+] [-] igl|11 years ago|reply
A good read on the subject of performance and native method replacements:
https://github.com/codemix/fast.js/tree/master#how
[+] [-] divmain|11 years ago|reply
[+] [-] andrey-p|11 years ago|reply
[+] [-] esamatti|11 years ago|reply
[+] [-] msoad|11 years ago|reply
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
[+] [-] iamleppert|11 years ago|reply
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.
[+] [-] spicyj|11 years ago|reply
[+] [-] tjholowaychuk|11 years ago|reply
[+] [-] tjmehta|11 years ago|reply
[+] [-] heydenberk|11 years ago|reply
[+] [-] neals|11 years ago|reply
[+] [-] weavie|11 years ago|reply
[+] [-] rco8786|11 years ago|reply
I'm confused, the majority of this library seems to be wrapper functions for built-in vanilla js operations.
[+] [-] tjmehta|11 years ago|reply
[+] [-] fruchtose|11 years ago|reply
[+] [-] tjmehta|11 years ago|reply
I was thinking `throw new Error('You're doing it wrong');` :-P
[+] [-] vlunkr|11 years ago|reply
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
[+] [-] city41|11 years ago|reply
https://github.com/tjmehta/101/blob/master/test/test-and.js
[+] [-] abelnation|11 years ago|reply
[+] [-] noisysocks|11 years ago|reply
[+] [-] tkmcc|11 years ago|reply
[+] [-] tjmehta|11 years ago|reply
[+] [-] theDustRoom|11 years ago|reply
[+] [-] insin|11 years ago|reply
[+] [-] mkoryak|11 years ago|reply
[+] [-] bzalasky|11 years ago|reply
[+] [-] _RPM|11 years ago|reply
[+] [-] Kiro|11 years ago|reply
[+] [-] ttty|11 years ago|reply
[+] [-] anonfunction|11 years ago|reply