Hacker News Reader

Comment by jlongster | Hacker News Reader

Arrow functions don't break anything, they just add a little bit of complexity. And trust me, once you start using them, you'll never go back. That is one thing that TC39 absolutely got right; it solved a direct pain point in JS code and it's far easier to write good code with it.

I work on the Firefox Debugger, and all the devtools use ES6 extensively, especially arrow functions. They aren't confusing. Almost always, `this` refers to the object instance that you are working on, and arrow functions allow you to do quick functional programming inside the methods. It's beautiful.

View on HN

Yeah, pretty much the only time you want non-arrow functions is for prototype methods (but once ES6 classes are implemented, you can use that syntax and it will be less verbose anyways). In almost every other case you either don't care about `this` or you want to use the containing function's `this` value. Arrow functions are perfect for these cases.

I would just point out the ambiguity while working with legacy code and ES6 applications. (A separate name would have been fine. But of course, there is the reserved names problem.)

From a practical perspective, we will have to deal with IE 8 and co for another 10 years at least. So we will have to "come back" all the time.

Hmm, reading the Harmony specs, an arrow function asserts ' typeof () => {} === "function"' and 'Object.getPrototypeOf(() => {}) === Function.prototype', but is not subject to `apply` and `call` (for obvious reasons).

Isn't this an issue with patterns, where an object is applied to a callback? It would introduce extensive testing, whether the callback was supplied as a regular function or (erroneously) as an arrow function (which would raise an error). Using try-catch for this would send the whole construct out of JIT-context at the other hand, so it isn't a favorable option.

Note: You may still use `call` and `apply` on them to supply arguments, but you may not change the this-object. (So, they are still subject to these calls. But this does not affect the use-case given above, where an object would be applied to a callback.)

But the same `this` will have different semantics, depending on the context (is it a function or object, or is it an arrow function?). Also, strict mode will be ignored for this (rather than overriding standard behavior). This is introducing ambiguity in two separate fields.

A not-so-serious proposal: Since everyone is overwriting the variable "self", we could reuse the variable "parent" for the same reasons in this case.

Reply on news.ycombinator.com