Thanks for this article; it’s interesting to take a second look at a much-loved feature and evaluate if it’s really worth it. I kinda feel like you’ve convinced me that it is worth it, though, so your article may have caused the opposite reaction that you expected!

3 million ops/sec is more than fast enough for me, so the performance is negligible, and shouldn’t be a factor at all. Nobody should be optimizing fractions of microseconds.

The other thing, of course, is we’re just looking at transpilation, which is a temporary condition; eventually we won’t need to transpile class property arrow functions, and so unless there was a serious problem with it, its transience ought to make it a non-issue.

Also, I’ve never felt the need to mock or extend a React component; the arguments you make are valid for non-React classes, but I try to avoid classes outside of React. Are there reasons to mock React components that I’ve just never encountered?

As for @autobind, I feel like a better solution to “let’s make it easy to preserve context” is “let’s make context something you don’t even have to think about”. If we get in the habit of always using arrow function class properties, we remove a decision from our thought process; we will just always preserve context, and so there’s no need to hem and haw over whether @autobind is necessary!

As a bonus, in React terms, this will provide nice delineation from lifecycle hooks and custom methods, since lifecycle hooks will be the only ones not done with arrow functions.

Finally, arrow functions will still be nice to have for things like currying:

class Thing extends Component {
  updateField = field => value => { ... }
  updateFirstName = this.updateField('first-name')
  updateLastName = this.updateField('last-name')
}

I hope this doesn’t come off as combative — I really enjoyed this article, very well-researched and written. But yeah, unless I’ve missed something, I’ll continue happily using arrows :)