4 ms·

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 boun

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?)
      - orange8 7y ago
        Looking at your comment history, seems like anyone who technically differs with you gets downvotes, I'm sure that's not how it supposed to work, bring it on anyway. > That doesn’t sound true. Do you have any evidence? Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it. Remember, an arrow function shares the same scope with it's parent function, so when I say outside it's scope, think grand-parent or higher.
        minitech 7y ago
        > Looking at your comment history, seems like anyone who technically differs with you gets downvotes, I'm sure that's not how it supposed to work, bring it on anyway. Probably a side-effect of what I usually choose to comment on, which are things that are objectively wrong or seriously misleading :) I think the HN voting system is poor, so I don’t use it, myself. > Remember, an arrow function shares the same scope with [its] parent function Exactly like a non-arrow function, then? > Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it. Not only is that not evidence, it doesn’t support what you originally said. Slower ≠ crashing for no apparent reason. If you mention which version of Node this was, I can go looking for evidence.
        orange8 7y ago
        > Probably a side-effect of what I usually choose to comment on, which are things that are objectively wrong or seriously misleading :) I think the HN voting system is poor, so I don’t use it, myself. Do you have any evidence that you do not use it? > Remember, an arrow function shares the same scope with [its] parent function >> Exactly like a non-arrow function, then? No, not exactly. It looks like I need to be more explicit, here goes: Remember, an arrow function's BODY shares the same scope with its parent function > Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it. >> Not only is that not evidence, it doesn’t support what you originally said. It is called ANECDOTAL evidence, and yes, it is a thing. If you want SCIENTIFIC evidence, sorry I just do not have the time and energy. If you want to believe that arrow functions are a drop-in replacement for normal functions and that they are always better and faster in all situations, go ahead and believe that. And you'll do just fine, as long as all you are doing with JS is React and basic UI wrangling stuff. > Slower ≠ crashing for no apparent reason. My friend, this is a discussion, not a scientific thesis or a legal document. I do not have to explicitly explain every little detail and cover every little phrase so that someone does not misqoute me. Be generous enough to try and understand something someone is saying. So, to rephrase that too, when I say "crashing for no apparent reason" I mean "crashing for no apparent reason that I could find by looking at the code over and over again searching for bugs or typos". And yes, it was crashing due to timeout and memory issues. Please dont start arguing about how crashing and timing out are not technically the same thing.

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?)
    - orange8 7y ago
      Looking at your comment history, seems like anyone who technically differs with you gets downvotes, I'm sure that's not how it supposed to work, bring it on anyway. > That doesn’t sound true. Do you have any evidence? Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it. Remember, an arrow function shares the same scope with it's parent function, so when I say outside it's scope, think grand-parent or higher.
      - minitech 7y ago
        > Looking at your comment history, seems like anyone who technically differs with you gets downvotes, I'm sure that's not how it supposed to work, bring it on anyway. Probably a side-effect of what I usually choose to comment on, which are things that are objectively wrong or seriously misleading :) I think the HN voting system is poor, so I don’t use it, myself. > Remember, an arrow function shares the same scope with [its] parent function Exactly like a non-arrow function, then? > Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it. Not only is that not evidence, it doesn’t support what you originally said. Slower ≠ crashing for no apparent reason. If you mention which version of Node this was, I can go looking for evidence.
        orange8 7y ago
        > Probably a side-effect of what I usually choose to comment on, which are things that are objectively wrong or seriously misleading :) I think the HN voting system is poor, so I don’t use it, myself. Do you have any evidence that you do not use it? > Remember, an arrow function shares the same scope with [its] parent function >> Exactly like a non-arrow function, then? No, not exactly. It looks like I need to be more explicit, here goes: Remember, an arrow function's BODY shares the same scope with its parent function > Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it. >> Not only is that not evidence, it doesn’t support what you originally said. It is called ANECDOTAL evidence, and yes, it is a thing. If you want SCIENTIFIC evidence, sorry I just do not have the time and energy. If you want to believe that arrow functions are a drop-in replacement for normal functions and that they are always better and faster in all situations, go ahead and believe that. And you'll do just fine, as long as all you are doing with JS is React and basic UI wrangling stuff. > Slower ≠ crashing for no apparent reason. My friend, this is a discussion, not a scientific thesis or a legal document. I do not have to explicitly explain every little detail and cover every little phrase so that someone does not misqoute me. Be generous enough to try and understand something someone is saying. So, to rephrase that too, when I say "crashing for no apparent reason" I mean "crashing for no apparent reason that I could find by looking at the code over and over again searching for bugs or typos". And yes, it was crashing due to timeout and memory issues. Please dont start arguing about how crashing and timing out are not technically the same thing.