I was stunned by the reults described in this answer and supported by this benchmark that compares that solution (native JavaScript) with the one I proposed (Lodash).
I've also compared the proposed solution:
const obj = {
name: undefined,
age: 15,
school: 'Some school'
}
const hasOnly = (obj,props) => {
var objProps = Object.keys(obj)
return objProps.length == props.length && props.every(p => objProps.includes(p))
}
console.log(hasOnly(obj,['name','age'])) //return false
console.log(hasOnly(obj,['name','age','city'])) //return false
console.log(hasOnly(obj,['name','age','school'])) //return true
with one where I truly simply switch from every native function to the corresponing function in Lodash,
hasOnly = (obj,props) => {
const objProps = _.keys(obj)
return _.size(objProps) == _.size(props) && _.every(_.includes(objProps), props);
}
and the result is still disappointly in favour of the native solution.
Now, the one above might be a silly example, but still... > 90% slower? Then what am I using Lodash for? I mean, in different scenarios it can improve readability, expecially when funtions have to be partially applied and passed around, where Lodash saves you from a lot of x => x. (classic example arrayOfarrays.map(_.map(fOnTheElements)) instead of arrayOfarrays.map(arr => arr.map(fOnTheElements))), but if the peformance is so low, then it's a bit hard to make the expressivity enough to choose Lodash over native code.
I'm new to JavaScript and Lodash (just not totally new to functional programming), so I don't even know the reliability of the benchmark tool that was used in the linked answer, but I can't believe it makes such a bad job that reverses the result.
Lodash is just javascript. There's no magic that can make it faster than the native code it is written in.
In short, every method call has an overhead. So if I do
const len = myArr.length
and you do
const len = _.size(myArr);
and we assume the implementation of _.size is
function size(arr){
return arr.length
}
(It does more than that, but stay with me here!) Then at very least you have an extra method call that the native solution does not.
In actual fact _.size does even more than just check the length
Gets the size of collection by returning its length for array-like values or the number of own enumerable string keyed properties for objects.
So on top of an extra method call you have the code for checking the "number of enumerable string keyed properties" - is it really any wonder that a native solution is quicker?
So why use a library like lodash? Because as their documentation headlines:
Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc.
So, you sacrifice a bit of speed for readability and ease of use.