[shiv86]

>The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times.

Incorrect - The main advantage is fat arrow syntax can keep lexical scope of this current context. Hence you dontneed to implement that=this antipattern

[la12]

In that case, they should have deprecated the "function(){}" notation or at least made it such that arrow function doesn't overlap it.

The current scene is that most people don't know what the real difference between arrow and function notations and this leads to a lot more number of bugs than if they weren't this overlapping. Overall, my point is, this just leads to poor ergonomics and you'll have a larger number of avoidable bugs.

[hombre_fatal]

> The current scene is that most people don't know what the real difference between arrow and function notations

That's hard to believe unless you're working on the most amateur of teams.

There's a point where you have to expect people to understand the most basic concepts of the language/tools they're hired to use. This shouldn't require more than a simple 5min pull-aside of the junior developer.

Also, you can't change function(){}'s dynamic scope without breaking the web, which is a major downside for your suggested upside of developers not having to learn the distinction. function(){} was always confusing from day one. ()=>{} is a move back toward intuitiveness.