Why I Don’t Use Arrow Functions With const/let

Arrow functions are great. I love how concise and easy to read they are, but I only use them in a two specific situations. In all other scenarios I use normal functions. In this video I talk about what those two scenarios are and why I prefer to use normal functions in all other cases.

🌎 Find Me Here:

⏱️ Timestamps:

00:00 - Introduction
00:38 - #1 Reason I Use Normal Functions
02:35 - When I Use Arrow Functions
05:09 - Another Reason To Use Normal Functions

#ArrowFunctions #WDS #JavaScript

[ribasenric]

This IS the reason I like them. :)
Put helpers functions in another file and load it

[Elefantoche]

The first reason is actually why I like arrow function over classic function definition. Code flow for me goes from definition to implementation from top to bottom, instead of what you mention about "important" code at the top. If I need something I like to know this "something" exists before trying to use it, and using arrow function along const enforces just that.

[ProwlerDigital]

It’s refreshing not seeing a title like “STOP DOING THIS” whenever I see that, I just scroll passed the video

[Radekbossboss]

The first reason is why I use arrow functions, i have to have some structure in my code not random mess with fn declarations between usage

[MaxPicAxe]

My opinion.

1. Hoisting -- I personally prefer to write code in this order anyway, the outer layers (i.e. the main logic) is further down, so I always jump straight to the bottom of a file if I want to know what's getting executed. I guess this just might be preference. I also come from a background of pure mathematics where everything is structured in a way where there is no hoisting, everything is ordered naturally, that is, sequentially.

Regarding your example with helper functions, these can always be moved to a different file, that makes more sense if you believe there should be a separation.

[catsgotmytongue]

as an engineer who has coded in many languages over 20 years, JS is the one that is the most painful to deal with BECAUSE of 'hoisting' and the changing context of 'this' depending on how it's called. Among other things, JS has so many odd quirks that make it a pain compared to many other languages.

[dasten]

I agree on using the function keyword for defining small helper functions. But I still like to define them before using them.

[yorutamashi]

i think that calling things AFTER defining them makes much more sense, I get super confused when the file doesn't have to respect a specific order... and seeing that so many people do terrible crap when they are not forced by linters or interfaces like typescript, I think it's very much needed to adapt to these better practices

[OrelNaya]

for the first reason you mention, I think it's better to split the code to multiple files so when you use them you just import them where you use them

[undisclosedperson]

Reason 1 is also why I use arrow functions. Not out of puritanical belief or anything, but the backend language I work with the most is F#, which requires everything to be declared before it can be used. And when writing functional Javascript (or especially Typescript), the languages are actually extremely similar and I think it's the best functional approach. F# enforces order of files too, which can't really be done in Javascript, but I wish it could be.

[codingman]

I think arrow functions do not require context switching, I may be wrong. Thus for small snippets of code I prefer using arrow functions and for larger snippets I use normal functions. As for organizing code, whether I write code at top of my file or bottom doesn't matter to me that much due to modularity, I do not write any thing else in the main script rather one main function and then calling it. But that's just my style. Honestly I do feel all the rules and guidelines for writing clean code is meaningless if your code is not performent. Most of the time this leads to unnecessary abstruction that often have many unnecessary instructions that are not needed but still called only to keep the structure "clean". For example, looping over same array multiple times in different functions where everything could be done in a single loop causing much less memory access (one of the biggest bottlenecks). Javascript is not a compiled language, but and interpreter. So from compiler diesign perspective, the optimization done by jit compilation is no where near like languages like c, where compilation in release mode throws away all the fancy abstruction and completely reorganize only performent code. Sadly dueto the dynamic nature of js and being and interpreted language this is not possible. So developers should be mindful of the cercumstences. However again it depends on how performent one wants his code to be. For a dataview kind of website it doesn't matter, but for things that requires high amount of computation it matters. As an example, working with canvas 2d if you floor the arguments before passing them to the function, you will see a significant boost in performance. The reason is simple, interpreters are not as smart as compilers when it comes to optimization.
The point I want to make is that function calls have costs .

[darklorddracula]

Why would you define the utility function in the same file you call them ?

[devhelp]

Slight correction in your event handler, "this" is the same as event.currentTarget, not event.target. The target is the element that was clicked on while currentTarget is the element with the event handler.

[ZakiWasik]

On a real production project I almost certainly will have each of my functions in a separate file (excluding anonymous functions and callbacks) and when passing callbacks I usually want to bind the parent context like it is default with arrow functions, so I'm the opposite: I use the function keyword only when an arrow function does not cut it. Which is rare.

[afzalhamdulay]

this video wasnt much much about syntax but more about logic. this was actually awesome knowledge that you gave. thanks!

[rodrigolaporte]

Ok, so now I have two things I disagree with you: not using semicolons, and now the arrow functions :P
To me, having to define the functions before they're used is not an issue, but a plus. It helps when you work on a team where usually a few devs are messy with their code, so these small things that force you to be a bit more organized are really helpful. Same goes for some people's neverending creativity for using 'this'. With arrow functions we avoid several errors that cause bugs. So in the last few projects I've worked on, we use the opposite strategy: everything's an arrow function except for some specific cases.
As for the syntax, it's just preference/getting used to.
Anyways cool video, it's nice to see different approaches / trains of thought.

[brettc]

Love your channel, man. I love that your videos are concise and straight to the point. Learn a few new things everytime I watch your content, even if it's a topic I already know well and you give me a different perspective on it.

[subliminakeys]

I thought I was alone with this concept. I hate using const over function. Most of the reasons you said but primarily because when I'm scanning code for a variable or function I don't want everything to look like a variable. And hoisting, I don't want to worry about where I'm defining my function.
The funny part is it's not even really any shorter of syntaxes. Const name () => is is literally one less character than function name() . You can omit the brackets in arrows but I often use them anyway.

[kyow]

as solo dev its okay but when you work with code that someone else wrote, hoisting is pain in the ass
because in comparison, if there are no strict rules where we should place functions, hoisted functions is immediate "peek definition", because they can be lower in file or higher, whilst arrow functions enforce you to define them before using, that makes them not significantly easier but quite a bit, also no "this"
after dealing with class components in react i truly started hating hoisting

[neontuts]

Thanks for sharing Kyle. I prefer to use the utils file to store the helper functions and import it to the main file.