Arrow functions are not a silver bullet!

I see people jump onto the arrow functions bandwagon without thinking twice about it, be it by laziness or hype following. You should still keep in mind that arrow functions are not the be-all, cure-all of functions! There are many cases when they’re actually a bad idea:

  1. If I want to take advantage of the hoisting that JavaScript applies to traditional function declarations, that is, I want to be able to call a function in its declaring scope, ahead of its declaration. I need to use a traditional function declaration for this, not a function expression. Arrow functions are by their very nature expressions, so this won’t work. By the way, if you’re not too clear on what hoisting is and does, I put a small link here to help clarify that; we also talk about it in detail in our video course on Writing Modern Async JavaScript, and obviously in our kick-ass 360° ES in-room training course.
  2. If I do need my function to be callable with an explicitly-defined this, perhaps to pass it to APIs that rely on such a contract, as we saw earlier, I just can’t use an arrow function! Event handlers needing to access the target object or stream, test functions that need to customize their timeout… all of that requires a traditional function in order for the calling code to be able to set up the proper this.
  3. Just playing the Devil’s advocate here, but I would also need a traditional function if I wanted to tweak arguments. Now, since ES2015 we don’t use arguments much: using the rest syntax in the signature is much nicer in every way. And if we have arrow functions, we’re at the very least on ES2015.

No need to get pedantic

Allow me to make a quick side note here towards those who’re just bursting with the temptation to go pedantic in the comments (unfortunately, there are always a couple such folks) by going Well, Actually on me and nitpicking the details of what the JS engine actually does under the hood and blah blah blah…

Yes, sure, I did slightly simplify the issue (although in truth we're pretty darn close to the implementation level here), but let me remind you that we’re not re-implementing a JS engine. I believe we already went pretty far to explain properly and accurately the behavior of this, which is the core topic of this course, remember?

Now if that won’t deter you from spewing bile, just remember that I know perfectly well the FER is set up using the [[ThisBindingStatus]] internal slot to check that it evals to 'lexical' (as explained by section 8.1.1.3 of the spec, did you even read it?), that this in turn is based off the [[ThisMode]] internal slot from the function’s definition (section 8.1.2.4), which is set to 'lexical' for arrow functions (section 9.2.4), etc. I interact with TC39 and read the spec, and I say that on this one, we went far enough and you can swallow that “Well actually” right back and save us all some grief.

There are plenty more constructive opportunities for commenting on this course, I'm sure.

JavaScript: this is it

You’ll finally understand how this works in JavaScript… And you can bet it’s worth it!

Already enrolled?
Sign in to continue learning.