I don't like ambiguity in code. When I'm reviewing code and have to stop and figure out what this is referring to, it makes me frown; with arrow functions I always know exactly what this is. The 'swap this and that' pattern in JS always struck me as a hack. One of the big wins of arrow functions is eliminating the this ambiguity.
I have a similar feeling for hoisting. I understand why it is part of the language, but it always feels like a path to ruin when I have to rely on some behind-the-scenes reshuffling by the interpreter to get my code to run.
All that said, you are correct that there are situations in which arrow functions are not appropriate, which also make me crazy. Having two ways to write functions just adds confusion. "We recommend using arrow functions everyhwere. Oh, sorry, was that a constructor? Write that one this way instead..."
I can't wait to start seeing code in review that's built with templated classes. Maybe ES7 will introduce header files...
Haha! I totally understand what you mean. But still since ES6 introduces class we should really move away from using function as a constructor. As soon as it is consistent in a team then it's fine.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.