What's there to implement? Just use an arrow function
// typical use-caseconstupperCaseStrings=lowerCaseStrings.map(s=>s.toUpperCase())// if you need it oftenconstupperCase=(s)=>s.toUpperCase()constupperCaseStrings=lowerCaseStrings.map(upperCase)
But inline arrow functions are recreated every time they are evaluated. This may not be a problem in most circumstances. But in React, passing an inline function to a pure component causes it to re-render every time its parent renders; passing the same exact instance of a function may result in a significant performance boost. It may be an edge case, but it's one that I've actually encountered several times.
Yes, you can define the function somewhere else if you need it often. But then you've just reimplemented the package, proving that it does actually serve a purpose.
This is a micro optimization fallacy. As every single performance analyst, and even the V8 engineers have said multiple times (there's some good talks on youtube) - don't micro optimize.
Now that we've got that out of the way, let's talk about optimization. As I just so happen to be somewhat obsessed over it too :P. Since around the mid 2010s (2015 maybe? Can't remember), V8 (the state of the art VM most javascript runs on) has inline cache. This is why higher order functions suddenly saw a massive speed boost around this time. You may remember people telling you to not use higher order functions prior to this change. There is a stack overflow thread summarising the details of the aftermath. I remember it being about different array iteration methods and their speed.
Anyway, that's the inline cache for optimizing out inline lambdas. If we want to go into nitty gritty details, the cache is actually for all expressions in Applicative Normal Form.
Anyway, this is far from being the only optimizing technique V8 has - it's supposed to make javascript ridiculously fast, so it has a state of the art JIT.
The point of all this effort from some of the greatest engineers of all time, is so that users won't care about highly superficial "optimizations" such as avoiding arrow functions.
By the way, is storing the arrow function in a variable, then using that, considered worse than pulling in an entire dependency? ;)
(this is a joke - don't actually store all your arrow functions in variables out of paranoia, for reasons mentioned above)
I understand all that, and I agree that you generally shouldn't worry about inlining functions. But the example I gave was pure components in React. Pure components check the properties they are passed with Object.is() every time their parent component renders. If all the properties are the same as the last render, the pure component can skip rendering, which may be a significant performance boost when rendering complex components or lists, for example. If you pass an inline function, Object.is() always fails, so you break the optimization that pure components provide. There is a React hook called useCallback() designed to circumvent this problem, but for simple cases like upperCase(), it's unnecessarily verbose.
Yes, you can easily define the function yourself, which is what I do. But if it's useful when I define it myself, then it's useful when someone else defines it in an NPM package.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What's there to implement? Just use an arrow function
But inline arrow functions are recreated every time they are evaluated. This may not be a problem in most circumstances. But in React, passing an inline function to a pure component causes it to re-render every time its parent renders; passing the same exact instance of a function may result in a significant performance boost. It may be an edge case, but it's one that I've actually encountered several times.
Yes, you can define the function somewhere else if you need it often. But then you've just reimplemented the package, proving that it does actually serve a purpose.
This is a micro optimization fallacy. As every single performance analyst, and even the V8 engineers have said multiple times (there's some good talks on youtube) - don't micro optimize.
Now that we've got that out of the way, let's talk about optimization. As I just so happen to be somewhat obsessed over it too :P. Since around the mid 2010s (2015 maybe? Can't remember), V8 (the state of the art VM most javascript runs on) has inline cache. This is why higher order functions suddenly saw a massive speed boost around this time. You may remember people telling you to not use higher order functions prior to this change. There is a stack overflow thread summarising the details of the aftermath. I remember it being about different array iteration methods and their speed.
Anyway, that's the inline cache for optimizing out inline lambdas. If we want to go into nitty gritty details, the cache is actually for all expressions in Applicative Normal Form.
Anyway, this is far from being the only optimizing technique V8 has - it's supposed to make javascript ridiculously fast, so it has a state of the art JIT.
The point of all this effort from some of the greatest engineers of all time, is so that users won't care about highly superficial "optimizations" such as avoiding arrow functions.
By the way, is storing the arrow function in a variable, then using that, considered worse than pulling in an entire dependency? ;)
(this is a joke - don't actually store all your arrow functions in variables out of paranoia, for reasons mentioned above)
I understand all that, and I agree that you generally shouldn't worry about inlining functions. But the example I gave was pure components in React. Pure components check the properties they are passed with
Object.is()every time their parent component renders. If all the properties are the same as the last render, the pure component can skip rendering, which may be a significant performance boost when rendering complex components or lists, for example. If you pass an inline function,Object.is()always fails, so you break the optimization that pure components provide. There is a React hook calleduseCallback()designed to circumvent this problem, but for simple cases likeupperCase(), it's unnecessarily verbose.Yes, you can easily define the function yourself, which is what I do. But if it's useful when I define it myself, then it's useful when someone else defines it in an NPM package.