5 ms·

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

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.

nawitus 12y ago
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.
serve_yay 12y ago
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 12y ago
  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.
frik 12y ago
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/Ecma-357.htm 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 12y ago
  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 12y ago
    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 12y ago
      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.html http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...
lomnakkus 12y ago
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 12y ago
  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 12y ago
    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! ;)
pcthrowaway 12y ago
> 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.

nawitus 12y ago

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.

serve_yay 12y ago

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 12y ago
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.

frik 12y ago

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/Ecma-357.htm 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 12y ago
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 12y ago
  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 12y ago
    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.html http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...

lomnakkus 12y ago

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 12y ago
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 12y ago
  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! ;)

pcthrowaway 12y ago

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