I see a lot of code here using the traditional function keyword. I haven’t used the word function in my code for over three years. What is the advantage of using the word function in contrast to arrow functions not only as closure arguments but constants.
const hello = name => console.log(‘hello ‘ + name)
I never see code like that here. It is always function declarations.
function hello(name) { console.log(‘hello ‘ + name) }
There’s the obvious with binding this. Albeit you can still use arrow functions with partial application due to them not having their own this property you can’t bind them to a context.
In addition I don’t think you can have named arrow functions, can you? Which means they can’t be used recursively like this.
const foo = bar(x) => {
if (not basecondition) bar(x)
return x
}
Where as with old style function definitions you can
const foo = function bar(x) {
if (not basecondition) bar(x)
return x
}
I think part of the reason you see the word function here, is because you have novices who are new to JS, and it’s a case of keeping things simple. I could be wrong 
You can assign arrow functions to constants in JavaScript
const doYouUnderstand = b => console. Log((b ? ‘Yes’ : ‘No’) + ‘ that is my understanding’’)
Yes that’s right.
To be honest, I am not a fan of code shortening for the price of readability.
Function doSomething(b)
{
Some code to do
}
Is for me much easier to read then
const doSomething = b => Some code here
This reminds me at the beginning of C programming when all people tried to put as much code as possible in one code line. The code was unreadable but looks pretty cool
But this may also be because I have written code for over 30 years before arrow functions were invented.
At the end you gave yourself the answer. Even if you have never used this function keyword, you directly understood how it works and what it does.
The other way around is much less intuitive.
No one will know what => means if he is new to JavaScript.
I know where you are coming from, it possibly starts to fall into the category of obfusication.
That said if you are keeping your functions short and sweet, then arrow functions I find are more readable.
For instance I prefer
const add = x => y => x + y
to
function add(x) {
return function(y) {
return x + y
}
}
In addition the fact arrow functions don’t have a ‘this’ property instead relying on lexical scoping does have one advantage of not having to do daft things like var that = this
const obj = {
x: 5,
outputX () {
setTimeout(() => console.log(this.x), 1000)
}
}
instead of
const obj = {
x: 5,
outputX () {
const that = this
setTimeout(function() { console.log(that.x) }, 1000)
}
}
edit: I do bow down to your 30 years of coding experience though 
I too prefer the former, with one small addition, and that is to include the parameter parenthesis as well.
const add = (x) => (y) => x + y
That way you don’t have to study quite as hard the different equals and arrow signs to understand just what is going on. and there is a consistent presentation of the function parameters regardless of whether there are one or more of them.
The arrow notation has a strong visual benefit for me when it’s on a single line. When arrow functions require multiple lines and function braces though, that is when I prefer to use function notation instead.
I guess I don’t really consider readability as much as I once did considering most of the code I write runs in the browser and most of time I’m using breakpoints to read code. Additional functional reactive programming tends to be better suited using arrow functions which is most the time what I deal with. Little reason to scatter function everywhere when passing functions as arguments . Most the time when doing that it is also nice to maintain the object context as well which is an inherent part of arrow functions.
I’d go with that 
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.