[peferron]

My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing.

Iteration:

  for (var i = 0; i < y.length; i++) { ... }
  for (var x in y) { ... }
  for (var x of y) { ... }
  y.forEach(function(x, i) { ... })
  Object.keys(y).forEach(function(x) { ... })

Comparison:

  ==
  ===
  Object.is() (would have been a good laugh if introduced as ==== instead)

Of course, this doesn't matter much if you're a single developer. I've started writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for projects built by many developers of varying experience levels. The nice things about smaller languages is that there's often only one way to do something, so when you write code or review other people's code, your mind is free from the minutiae and you can focus on the big picture instead.

It's a bit funny that it's when JS is, from the general consensus, finally getting "better" that I'm actually considering more and more switching to a small but well-built compile-to-JS language. I guess smallness and simplicity just matter a lot to me.

[serve_yay]

Object.is is a very silly addition to the language. It does the same thing as === except in the case of NaN and positive/negative zero.

I mean if you read a polyfill for it, it's such a silly bit of "functionality". And of course the name is terrible. Argh.

[ender7]

The new Map and WeakMap classes use Object.is() to determine if two keys are the same (otherwise it would be impossible to use NaN as a key to a map).

Whether this algorithm should have been exposed to users is debatable, but it exists for a good reason.

[nawitus]

I would think that most languages suffer from this at least as much as JavaScript. The solution is to have guidelines and enforce them through code reviews. Linters can also catch some of the rules.

I'd say that JavaScript's benefit is that it's so simple that there are not too many solutions to do the same thing, unlike massive enterprise languages like C# and Java.

[lomnakkus]

Just looking at your example:

    for (var i = 0; i < y.length; i++) { ... }
    for (var x in y) { ... }
    for (var x of y) { ... }
    y.forEach(function(x, i) { ... })
    Object.keys(y).forEach(function(x) { ... })

None of the "for" variations are considered good practice in ES6. You should be using "let" (or "const" if it's allowed here) to avoid var-hoisting of "i".

Personally, I'd advocate using "for" if you have a need for early return/break/continue -- otherwise I'd go for the first forEach() variant. Or, even better, use "map" and avoid side effects in the function you're mapping over the collection. Unless of course you're doing something imperative.

The fact that the last forEach() variant is possible is a good thing, though I wouldn't recommend its use in this case because it's needlessly complex -- it shows that the language/stdlib is becoming more compositional.

[peferron]

Yes, "let" is better than "var". I could also have used a fat arrow in the forEach(). But my point was to list iteration variations, so outside of that I wrote traditional ES5.

This illustrates the issue though. "var" is like "let" but without block scoping, so you should almost never use "var", but it's still there to trip newcomers. The fat arrow is like the "function" keyword and most of the time you can use them interchangeably, but if you rely on "this" they're not interchangeable anymore.

This growing laundry list isn't exactly thrilling. I'm glad to have map(), filter(), every() and friends, though.

[lomnakkus]

Have a pre-commit linter disallow "var". (etc. for everything else.)

In a language like JS you cannot have it all, but at least appreciate the improvements! ;)

[frik]

I am unsure about some ES6 additions.

Thanks to Crockford we got a decent ES5. Remember that several syntax changes got postpones to ES6. And don't forget about "E4X", a beast that was supposed to be JavaScript 2? http://www.ecma-international.org/publications/standards/Ecm... It got similar traction as XHTML 2. Both had no backwards compatibility - an insane idea. Some new features in ES6 look like Crockford "good parts" movement lost and Sun/Oracle Java evangelists won.

Hopefully Douglas Crockford updates his "JavaScript: The Good Parts" in time for JavaScript 6.

[riffraff]

I really wish E4X had gotten traction. I wrote a firefox extension using it and it was awesome to do XUL + JS with it.

Years later

  var foo = <foo>{item}</foo>; 

is the new hotness in facebook's JSX.

[lomnakkus]

AFAIUI from the React people E4X had a lot of incidental complexity and extraneous stuff relative to JSX. So there's that.

I'd argue that with ES6, JSX could just reserve the "jsx" prefix for interpolated strings and go with

   jsx`<foo>blah</foo>`

but that's a typical hindsight-is-20/20-thing.

[insin]

This blog post - "JSX: E4X The Good Parts" - covers what's in and out for JSX:

http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...

[pcthrowaway]

> My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing

To be fair though, this has been an issue with Javascript since its creation (and has been getting worse as the language has been expanded while maintaining backwards-compatibility).

Many other languages have similar problems (Ruby is an offender that comes to mind, though it's perhaps not on the level of ES6+)

I'm not much of a polyglot, but one language which seems to have "one obvious way" as part of its design choices that springs to mind is Python. I have a hunch that pure-functional languages would be less choicy as well, though I have no familiarity with any.