6 ms·

const doThing = event => {} function doThing( event ){} Why does everyone seem to be using the first format? Isn't the second version a lot more readable/pret

const doThing = event => {} function doThing( event ){} Why does everyone seem to be using the first format? Isn't the second version a lot more readable/pretty? Even worse is when doThing is immediately exported and not refferenced anywhere else, but still there is this need to assign it to a const.

ng12 7y ago
Arrow functions help save you from `this` insanity.
- orange8 7y ago
  I agree, but do all functions use 'this'?
  - ng12 7y ago
    No, and part of the reasoning is to explicitly avoid the chance you might accidentally refer to the wrong `this`. There's an ESLint rule to enforce this: it will complain if you use a `function` without referring to the prototype this. Makes it handy because if I do use `function` I know it's because there's a reason -- e.g. some libraries still make heavy use of the local this. https://eslint.org/docs/rules/prefer-arrow-callback https://eslint.org/docs/rules/prefer-arrow-callback
    - orange8 7y ago
      The rule you link to is specific to "function expressions", which may or may not use 'this'. To ask the same question differently, what about functions that do not need 'this'?
      - ng12 7y ago
        I'm not sure what your proposal is -- use functions that use prototype this or no this, and arrow functions for ones that use contextual this? It's easier to use arrow functions for everything except for the tiny minority of cases where you want prototype this.
lhorie 7y ago
Many reasons. 1) Hoisting + mutability a = 'lol'; function a() {} a() // error 2) one-liners const findByName = (list, name) => list.find(item => item.name === name); //vs function findByName(list, name) { return list.find(item => item.name === name); } 3) signaling that `this` keyword usage should not happen
- orange8 7y ago
  And when you don't need any of that, how do you signal that you do not need it?
knathan 7y ago
3 reasons that I can think of: 1. You can implicitly return things so it provides nice syntactic sugar 2. Using an arrow function results in `this` being bound in the way you'd expect (coming from something like C++) in all cases without having to call .bind(this) anywhere. I'll never forget seeing promise chains starting with `const that = this;` in order to keep the right reference throughout the promises. 3. You use it for the previous 2 reasons and use it everywhere in order to be consistent
- orange8 7y ago
  I agree with one and two, and really appreciate arrow functions in those two, and other appropriate use cases. With three, I disagree. It is kind of like saying let us just use var everywhere to be consistent.
  - knathan 7y ago
    I fall into category 3 which is why I list it. It's not a technical reason so much as a code style reason so it is definitely subject to the opinions of each developer.
    - orange8 7y ago
      It is much more than a matter of code style. For example, an arrow function accessing variables outside its scope is much slower, something you will notice when processing a lot of data in nodejs. And if you're working in the browser and trans-pilling down to ES5, babel needs to do a lot more work. But as long as people are aware of the trade-offs, they can use whatever works for them.
      - minitech 7y ago
        > For example, an arrow function accessing variables outside its scope is much slower That doesn’t sound true. Do you have any evidence? (Under an uncommon JavaScript engine?)
sergeykish 7y ago
javascript function does too much. It is both method and closure. Which is not universal - io has method and block, ruby has def and block And it is constructor. So it can be called both with and without `new` with different results. Other can't: arrow = () => {} // new arrow() // TypeError: arrow is not a constructor object = { shorthand() {}, ['computed']() {}, get getter() {} } // new object.shorthand() // TypeError: object.shorthand is not a constructor // new object.computed // TypeError: object.computed is not a constructor // getter = Object.getOwnPropertyDescriptor(object, 'getter').get // new getter // TypeError: getter is not a constructor class Class { static staticMethod () {} method () {} get getter() {} } // Class() // TypeError: Class constructor Class cannot be invoked without 'new' // new Class.staticMethod // TypeError: Class.staticMethod is not a constructor // klass = new Class // new klass.method // TypeError: klass.method is not a constructor // getter = Object.getOwnPropertyDescriptor(Class.prototype, 'getter').get // new getter // TypeError: getter is not a constructor function* generator() {} // TypeError: generator is not a constructor // new generator() I actually was surprised just how many ways TC39 introduced so we do not use function. The change you observe is not a coincidence - it is carefully crafted.
- orange8 7y ago
  Let me get this straight: Are you saying all the changes in arrow functions, the class syntax and generator functions were all a carefully planned initiative to get rid of the "function" keyword because it does too much?
  - sergeykish 7y ago
    Yes, replace "function" usage with safe alternatives. And don't forget 'use strict' - it affected "function" too. "function" is too entrenched. It's usage as a constructor appeared even before .prototype: function Cat() { this.say = function() { return 'nyan' } } All the confusion about javascript object system is because of classes which have no name, we call them by their constructors. Give them real names: Cat = class {}.prototype // or function {}.prototype Cat.say = () => 'nyan' cat = new Cat.constructor cat.say() cat.__proto__ === Cat A little bit inconvenient... oh! it's everywhere: cat instanceof Cat.constructor Tom = class extends Cat.constructor {}.prototype And all the base classes are constructors Object = Object.prototype with their helper methods, it should be separate like Reflect and Math: Reflect.create = Object.constructor.create object = Reflect.create(Object) There is no simple answer, breaking change is not an option, let the planned obsolescence begin. And it works! Slow but steady so much done since 2012 http://brendaneich.github.com/Strange-Loop-2012/#/ http://brendaneich.github.com/Strange-Loop-2012/#/

ng12 7y ago

Arrow functions help save you from `this` insanity.

orange8 7y ago
I agree, but do all functions use 'this'?
- ng12 7y ago
  No, and part of the reasoning is to explicitly avoid the chance you might accidentally refer to the wrong `this`. There's an ESLint rule to enforce this: it will complain if you use a `function` without referring to the prototype this. Makes it handy because if I do use `function` I know it's because there's a reason -- e.g. some libraries still make heavy use of the local this. https://eslint.org/docs/rules/prefer-arrow-callback https://eslint.org/docs/rules/prefer-arrow-callback
  - orange8 7y ago
    The rule you link to is specific to "function expressions", which may or may not use 'this'. To ask the same question differently, what about functions that do not need 'this'?
    - ng12 7y ago
      I'm not sure what your proposal is -- use functions that use prototype this or no this, and arrow functions for ones that use contextual this? It's easier to use arrow functions for everything except for the tiny minority of cases where you want prototype this.

lhorie 7y ago

Many reasons. 1) Hoisting + mutability a = 'lol'; function a() {} a() // error 2) one-liners const findByName = (list, name) => list.find(item => item.name === name); //vs function findByName(list, name) { return list.find(item => item.name === name); } 3) signaling that `this` keyword usage should not happen

orange8 7y ago
And when you don't need any of that, how do you signal that you do not need it?

knathan 7y ago

3 reasons that I can think of: 1. You can implicitly return things so it provides nice syntactic sugar 2. Using an arrow function results in `this` being bound in the way you'd expect (coming from something like C++) in all cases without having to call .bind(this) anywhere. I'll never forget seeing promise chains starting with `const that = this;` in order to keep the right reference throughout the promises. 3. You use it for the previous 2 reasons and use it everywhere in order to be consistent

orange8 7y ago
I agree with one and two, and really appreciate arrow functions in those two, and other appropriate use cases. With three, I disagree. It is kind of like saying let us just use var everywhere to be consistent.
- knathan 7y ago
  I fall into category 3 which is why I list it. It's not a technical reason so much as a code style reason so it is definitely subject to the opinions of each developer.
  - orange8 7y ago
    It is much more than a matter of code style. For example, an arrow function accessing variables outside its scope is much slower, something you will notice when processing a lot of data in nodejs. And if you're working in the browser and trans-pilling down to ES5, babel needs to do a lot more work. But as long as people are aware of the trade-offs, they can use whatever works for them.
    - minitech 7y ago
      > For example, an arrow function accessing variables outside its scope is much slower That doesn’t sound true. Do you have any evidence? (Under an uncommon JavaScript engine?)

sergeykish 7y ago

javascript function does too much. It is both method and closure. Which is not universal - io has method and block, ruby has def and block And it is constructor. So it can be called both with and without `new` with different results. Other can't: arrow = () => {} // new arrow() // TypeError: arrow is not a constructor object = { shorthand() {}, ['computed']() {}, get getter() {} } // new object.shorthand() // TypeError: object.shorthand is not a constructor // new object.computed // TypeError: object.computed is not a constructor // getter = Object.getOwnPropertyDescriptor(object, 'getter').get // new getter // TypeError: getter is not a constructor class Class { static staticMethod () {} method () {} get getter() {} } // Class() // TypeError: Class constructor Class cannot be invoked without 'new' // new Class.staticMethod // TypeError: Class.staticMethod is not a constructor // klass = new Class // new klass.method // TypeError: klass.method is not a constructor // getter = Object.getOwnPropertyDescriptor(Class.prototype, 'getter').get // new getter // TypeError: getter is not a constructor function* generator() {} // TypeError: generator is not a constructor // new generator() I actually was surprised just how many ways TC39 introduced so we do not use function. The change you observe is not a coincidence - it is carefully crafted.

orange8 7y ago
Let me get this straight: Are you saying all the changes in arrow functions, the class syntax and generator functions were all a carefully planned initiative to get rid of the "function" keyword because it does too much?
- sergeykish 7y ago
  Yes, replace "function" usage with safe alternatives. And don't forget 'use strict' - it affected "function" too. "function" is too entrenched. It's usage as a constructor appeared even before .prototype: function Cat() { this.say = function() { return 'nyan' } } All the confusion about javascript object system is because of classes which have no name, we call them by their constructors. Give them real names: Cat = class {}.prototype // or function {}.prototype Cat.say = () => 'nyan' cat = new Cat.constructor cat.say() cat.__proto__ === Cat A little bit inconvenient... oh! it's everywhere: cat instanceof Cat.constructor Tom = class extends Cat.constructor {}.prototype And all the base classes are constructors Object = Object.prototype with their helper methods, it should be separate like Reflect and Math: Reflect.create = Object.constructor.create object = Reflect.create(Object) There is no simple answer, breaking change is not an option, let the planned obsolescence begin. And it works! Slow but steady so much done since 2012 http://brendaneich.github.com/Strange-Loop-2012/#/ http://brendaneich.github.com/Strange-Loop-2012/#/