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

Interesting take. Like a lot of the commenters, I define/declare functions at the top whether using the function keyword or arrow functions. I'll even look at my code below and go back up and cut/paste the functions in the order in which they are called. It just works with my brain that way. But I think one advantage to putting your "important code" at the top is that once the functions are written and tested, you might argue that there is no need to see them because when writing the "important code" and using tested/proven functions, you don't need to be concerned with the implementation. However, that is one of my issues. I always concern myself with the implementation. Slows me down sometimes. 🙂 Another thing I will say is that sometimes it takes a second to see whether something is a function or a const variable if they are all bunched together so it becomes more important for readability to use white space properly and have some order to defining const someFunc => oneliner; vs const someVar = value;

And I thought myself as being stupid or crazy since I hated arrow functions being used to create functional components in React. It's very confusing for me as a beginner!

Just put your functions in a separate file and import them. Then it doesn't matter which style of function you use. Hoisting won't be any concern. Besides many devs consider functions in a separate file(s) is best practice, I would agree with them...

Those functions should not be there in the first place. Your modules should be simple and concise, responsible of only one single purpose. Contrary to your claim, i use arrow functions everywhere rather than doing it old way. I respect your efforts and i learnt things from you (as a 20+ year experienced developer), though you sometimes come up with weird conclusions :)

IDK because it's never come up for me but I try to assume people say something for a reason and maybe I'm confused. Maybe the reason people say the this vs e. Target has to do with asynchronous behavior this is scoped to your function. I don't know how e scoping works but isn't it possible to have another event if you're using async? Then you'd need to error catch for that.

Again I'm not sure if event is scoped like that and I'll probably look it up but that could be why.

Hoisting is a cancer of Javascript. That's why no sane language uses it. If you want your important code to not be obscured by helper functions - you need to take them out to a different file. There is a logical order to defining a function and THEN using it. Hoisting is extremely difficult to reason about and so is best avoided!

Arrow functions are ugly and hard to understand

Meh, not compelling enough for me to switch and I like consistency more than "important code at the top". BTW, those functions are important too.

thank you so much, videos like this one (efficient, dense, clear) help me fill in the significant gaps i have in my knowledge

Thank you! I 100% agree.

thank you

Bro is still stuck in the 2010's 💀

I love how JS started with only regular functions and arrow functions came along to help add functional programming to JS, and now it seems that regular functions are deemed better in most cases all along. Go figure

Just use modules bro

what do you cook?

Arrow functions reference to this one level up

This is the most controversial video I've watched today.

This is weird. I have always used arrow functions for everything just because I felt it was the modern way to write code but this week when reviewing my code just began noticing how difficult it was to read where each function began and reverted to use the function keyword for all my main functions and arrow functions for anonymous functions.

Added good points about hoisting as well which I never considered!

thx

This is why I don't like hoisting~ Haha~

funny, I only use arrow functions, only use regular ones in specific scenarios

didn't work for me

const Person = {
name: "MasterYoda",
printName: function() {
console.log(this.name);
}
}
undefined
Person.printName()
undefined
const Person = {
name: "MasterYoda",
printName: () => {
console.log(this.name);
}
}
undefined
Person.printName()
undefined

I should make a video as to why I don't use JavaScript language as a backend language, it has way too many inconsistency.

Very interesting ! They teach to use arrow which to me is confusing

I want my important stuff at the bottom. Anyways, it's good practice to define things before you use it.

I feel like having code in the root of your file was your first mistake to begin with. Could be easily fixed with a main function, and happens rarely when using frameworks.

In the end it comes down to syntax preference, I think, it's just important to know the differences, and this video outlined them very nicely.

I tend to opt out of code that can mutate outside state by default. Using arrow functions/ closures that automatically capture state outside of their defined scope can open doors for silly bugs.

I think arrow functions are better because majority of the time I don't write a "const" variable as an arrow function... I put the arrow function directly in the code and use throw-away locally-scoped variables ("i", usually). I hate when code is written with a bunch of similar named variables (counter, Count, Counter, Counted, prevCount... etc) because it's harder to read and search through, so I nest the arrow functions and use BS variables like "i" (esp in methods)

Super helpful, thx!

Yea totally agree with all points👌 after my initial arrow function hype I moved back to normal functions in many cases

For reason 1, why don’t you just use modules ..

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.

And another argument against arrow functions! Great! I never liked arrow functions!

Abssollutely. Many devs make hype instead of correct usage

Your first "reason" seems exactly backward to me, making as much sense as placing all your imports at the end of a file instead of the start (which is probably where all those "utility functions" ought to be moved to, anyway---a separate file to import).

My rule is high level functions are in the form of named functions, while anonymous functions are arrow functions. Oh and no single letter variables outside of for loop indexes. Readability and maintainability drive the choices.

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.

I mostly use an arrow function as an equivalent to lambda in python. Other reasons are for dynamically changing class functions like for example the on_message of a websocket, as you described functions in objects or to define the function in a loop function like forEach etc. For the rest just the classic function as it is more readable and clear imo.

this dude in the video is an ant brain... sheesh

Please play that guitar for us one of these days.

I guess it's really just a matter of picking your poison. Both ways have their pros and cons.

Thanks for this. As a tech lead I use your entire channel to teach the “Dunning–Kruger Effect” and this video expands the syllabus.

I'm surprised arrow functions being much harder to debug because they have no name isn't a reason.

Dont hoist its really confusing and hard to follow…

Hoisting is a bug not a feature

Please get out of the 2010s and start using typescript for everything. These problems don’t even exist with TS and arrow functions are infinitely more readable when declaring generics and return types.

I always prefer arrow functions. Only in classes it is not allowed.

I prefer to read a function definition first and then I look up how it's used,
so the arrow functions don't pose a problem for me.