if you care to elaborate, what do you dislike about arrow functions?
1) If the problem is that the existing behavior for functions is occasionally confusing (which is true), I feel that adding a new syntax with different behavior is not exactly a perfect solution. Having two syntaxes* for functions with slightly different behavior is itself a confusing situation.
2) Â While arrow functions fix some of the gotchas of old-style functions, thatâs not the same thing as saying they donât have gotchas. Itâs just that we donât know what the gotchas are**.
3) This is partly a matter of taste, but I find the new syntax significantly harder to parse visually. Not for compact functions defined inline as subroutines (they look fine, even better, in that case***), but thatâs not the only way (or even the primary way, honestly) I see people use them. I say only âpartlyâ a matter of taste, because, while my personal aversion is probably idiosyncratic, the âhaving two different syntaxesâ thing is a problem here, too.
*Unlike other versions of new, improved syntax where the old way is only being kept around for compatibility purposes, like rest parameters replacing dumb tricks with the arguments object, youâll still need to use the old-style function syntax for some things.
**In fairness, itâs reasonable to say that we expect the gotchas to be less common. But I expect there to be some.
***Even there, though, would it have killed them to use characters that werenât already used in a bunch of short tokens? As of ES6, all of the following are valid JavaScript expressions meaning different things:
I mean, yeah, they had their reasons, but I donât have to like it.