If we want to talk about real production runtime cost, it depends what's your compile target:
Yes, arrows function get optimized when the target is the latest browser the dev is probably used, but as you support older browsers (consoles, old apple products, smart TVs, embedded systems, etc) arrow functions are not necessarily supported, and in those cases, they get compiled to standard function but that's bad for two reasons:
the compiler doesn't know if the intention is to use the "sugar syntax" or to bind the context of the function to the parent scope and takes no chances and always bind creating a triple scope in memory and code boiler plate for each function that exists
that boiler plate prevents some jit optimizations done by the browser that speed up javascript execution.
Always measure, but measure for your use case, not the one you can code in 1 minutes aside of the project.
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.
This is why micro-benching is dangerous.
If we want to talk about real production runtime cost, it depends what's your compile target:
Yes, arrows function get optimized when the target is the latest browser the dev is probably used, but as you support older browsers (consoles, old apple products, smart TVs, embedded systems, etc) arrow functions are not necessarily supported, and in those cases, they get compiled to standard function but that's bad for two reasons:
the compiler doesn't know if the intention is to use the "sugar syntax" or to bind the context of the function to the parent scope and takes no chances and always bind creating a triple scope in memory and code boiler plate for each function that exists
that boiler plate prevents some jit optimizations done by the browser that speed up javascript execution.
Always measure, but measure for your use case, not the one you can code in 1 minutes aside of the project.