[la12]

At this point, I'm convinced that Javascript is basically a jobs creation program.

We go on adding fancy new syntax for little or no gain. 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.

Similarly, python which was resistant to the idea of 20 ways to do the same thing, also seems to be going in the direction of crazy things like the "walrus" operator which seems to be increasing the cognitive load by being a little more terse while not solving any fundamental issues.

Nothing wrong with functional paradigm, but extra syntax should only be added when it brings something substantial valuable to the table.

Also, features should be removed just as aggressively as they are added, otherwise you end up with C++ where you need less of a programmer to be able to tell what a given expression will do and more of a compiler grammar lawyer who can unmangle the legalese.

[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.

[ptx]

> arrow function notation

Arrow functions bind this to the lexical scope, which is useful. (In a regular function the value of this depends on how it's called.)

> python which was resistant to the idea of 20 ways to do the same thing

This was in comparison to Perl which intentionally has an unusual excess of different ways to do things.

> "walrus" operator

Simplifies a very common pattern.

  m = re.match(r"my_key = (.*)", text)
  if m:
      print(m.group(1))

[dntrkv]

Arrow functions aren't just new syntax, they keep the context in which they are declared.

It allows devs to do the following:

onClick={() => doSomething()}

Without having to worry about binding the function to the correct context.

[phamilton]

Arrow function made `this` much more intuitive while maintaining backwards compatibility. That's definitely bringing something to the table.

[unilynx]

arrow functions are not just a function() alternative, but they solve the whole 'var self = this'/'.bind(this)' boilerplate.

It's one of the best JS improvements of the last 10 years.