8 ms·
Douglas Crockford on Fat Arrow Functions in JavaScript
- justinvoss 15y agoLooks really similar to Coffeescript. Is it safe to say that this new Javascript feature is a direct result of Coffeescript's influence? I hope so: Javascript is full of little horrors like the 'this' keyword, and it seems like it took a whole new language to convince people that it needs fixing.
- omgtehlion 15y agoFat arrow and yield operator? Looks more like c# to me...
- neilk 15y agoyield has been in Mozilla for ages, like, Firefox 2.x. The inspiration was python's yield.
- mattbriggs 15y agothe this keyword still works exactly the same, just a terse syntax for functions and for function binding to the current scope. currently, function(){} is the exact same as the proposed ()->{}, and (function(){}).bind(this) is the exact same as ()=>{}
- starwed 15y agoThis is not just about syntax. Unless using bind somehow grants the mentioned property that >"Fat arrow functions do not have prototype properties, which makes them cheaper to make. They are immutable."
- mattbriggs 15y agogranted, but that sounds more like a micro optimization rather then significantly changing the behavior of the language
- voidfiles 15y agoI think its absolutely because of languages like coffee script that JavaScript is changing, but don't take my word for it. You can find statments from standards makers to the same effect.
- batista 15y agoThe Harmony project (named differently in the past) existed long long before Coffeescript.
- voidfiles 15y agoI don't think it matters what came first. CoffeeScript has had a great effect on hearts, and minds because you can use it. It matters that CoffeeScript exists because people can wrap there head around new concepts and ideas. Only once people really understand an idea can we determine if it's good, or bad. Fat arrow is well understood in the JS community because of CoffeeScript, and that is one reason why people are pushing for fat arrow to be accepted. I personally think CoffeeScripts has had a very large impact on the idea.
- CJefferson 15y agoReally? I'd really like to see some references to that. These kinds of changes have been floating around for javascript since long before coffeescript.
- deleted 15y ago[deleted]
- voidfiles 15y agoThis is a great talk to watch about the development of JS. It's been a while since I watched it, but the point I was making, and the point I gleaned from this talk, is that new ideas need a test bed, and according to Eich Coffeescript is one of those places where new ideas are tested, and derived from. http://vimeo.com/27911873 http://vimeo.com/27911873 http://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/ http://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/
- jashkenas 15y agoI think it's safe to say. Arrow functions have existed in many different languages, but this particular flavor of using the fat arrow to declare a "lexical `this`" function, where the value of "this" within the function body preserves the value of "this" outside, is in CoffeeScript: http://coffeescript.org/#fat_arrow http://coffeescript.org/#fat_arrow
- eric_bullington 15y agoJeremy, would you mind sharing what the inspiration was for CoffeeScript's fat arrow? Was that token inspired by another language or was it something you just came up with on your own?
- jashkenas 15y agoSure -- the syntax for arrow functions has been floating around for ages, in Haskell, C#, and probably most relevant for me, the "stabby lambdas" in Ruby 1.9. One of the first ideas with CoffeeScript was to simplify function syntax, mostly because JavaScript's anonymous functions are so useful and pervasive that you end up with a lot of this: _.each(toRemove, function(key){ delete data[key]; }); ... where the "word" function there doesn't really tell you anything meaningful about what you're trying to accomplish. Arrows were appealing for a shorthand function syntax because of their visual representation of what happens in a (pure) function. Input goes in one side, output comes out the other. The input determines, or points to, the output. Since we use parentheses symmetrically to group parameters to a function, both when you define a function and when you call one, we arrive at this: (input) -> output ... or with our initial example: _.each toRemove, (key) -> delete data[key] That was the thinking. CoffeeScript actually originally used => for all functions, but the fat arrow distinction was introduced when we introduced bound (lexical "this") functions as an alternative to normal (dynamic "this") functions.
- eric_bullington 15y agoThanks for the detailed response. I thought it might have been inspired from Haskell or Ruby, but was surprised to find out that C# has a similar syntactic feature. So I was curious if there was an "official" etymology. Sounds like an amalgamation of all of the above.
- reginaldo 15y agoThe new functions do not have names, so you will need to use the old functions to write self-recursive functions. Or you can use the Y Combinator for extra fun... https://secure.wikimedia.org/wikipedia/en/wiki/YCombinator#Example_in_JavaScript https://secure.wikimedia.org/wikipedia/en/wiki/YCombinator#E...
- danbmil99 15y agoCan't you assign the function to a var and invoke that in the function body, like in Coffeescript? Otherwise I'm missing something.
- deleted 15y ago[deleted]
- jashkenas 15y agoJust realized that Crockford didn't link to it in his post. Here's the full proposal that Brendan Eich added to the ES Wiki: http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax http://wiki.ecmascript.org/doku.php?id=strawman:arrow_functi...
- robocat 15y agoThe part I found interesting was: "However, we don’t want CoffeeScript’s ->, it’s confusing to have two arrows and dynamic this binding is an oft-fired footgun."
- jashkenas 15y agoIt looks like Eich's original pitch was for both => (lexical this) and -> (dynamic this), but the latter was cut for political reasons. Out-of-band info from here: https://twitter.com/brendaneich/status/186156717506166784 https://twitter.com/brendaneich/status/186156717506166784 https://twitter.com/brendaneich/status/186160406300082176 https://twitter.com/brendaneich/status/186160406300082176 https://twitter.com/brendaneich/status/186162306521120770 https://twitter.com/brendaneich/status/186162306521120770 https://twitter.com/brendaneich/status/186162532367601666 https://twitter.com/brendaneich/status/186162532367601666
- robocat 15y agoThanks. Interesting!
- Cushman 15y agoI'd be interested to hear from any regular user of CoffeeScript who finds -> vs. => confusing.
- deleted 15y ago[deleted]
- maxbrunsfeld 15y ago
- Osiris 15y agoThe proposed function syntax looks exactly like C# lambda functions. Even the (this, x) => {} format is similar to how C# extension methods work. Extension methods require "this" to be the first parameter and define what objects the method can act on. It's really interesting to see that bleed over from a completely different type of language.
- ef4 15y agoFat arrows are one of the selling points for CoffeeScript, if you don't want to wait for ECMA6.
- TazeTSchnitzel 15y agoDoesn't fix the inefficiencies.
- snprbob86 15y agoRecent versions of CoffeeScript greatly improved compilation of fat arrows. This: x = (a) => y = (b) => z = (c) => @q * a * b * c Becomes this: var x, _this = this; x = function(a) { var y; return y = function(b) { var z; return z = function(c) { return _this.q * a * b * c; }; }; }; Instead of this: var x; var __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; }; x = __bind(function(a) { var y; return y = __bind(function(b) { var z; return z = __bind(function(c) { return this.q * a * b * c; }, this); }, this); }, this);
- starwed 15y agoTaze is (presumably) talking about the inherent inefficiency of all those functions having prototypes. (You know, the thing that was mentioned in the linked article?)
- Swizec 15y agoCan't wait for this to happen and gain widespread browser support so I can actually use it. JavaScript is a beautiful language trapped in a lame syntax, peppered with poor semantic choices based on what was considered "just the way it is" back then.
- voidfiles 15y agoIf its that important you could just use Coffescript while you wait.
- Swizec 15y agoSomething about using a language that is essentially syntax sugar for a different language just doesn't sit right with me. I'd much rather they fixed javascript, than use coffeescript. Although this might be unfair to coffeescript, I haven't given it a proper try-out yet :)
- armandososa 15y agoBut then you have to wait for browser adoption. Maybe you'll safely be able to use this syntax in 4 or 5 years.
- TazeTSchnitzel 15y agoThere's other places where we see JavaScript. For example in node.js, where you could use this stuff in production immediately.
- njharman 15y agoAll languages above assembler are as syntax surgary as coffee script.
- chc 15y agoDon't be silly — assembler is just sugar for machine code.
- jenius 15y agoHoly shit something that has been around for a while and works in all browsers now with coffeescript is now something we may be able to use with regular javascript in like 10 years! What's next, a for loop? Am i pushing it too far? (flame prevention: this is kind of a joke. i understand that it actually is pushing towards a better language, it's just such a slow and painful process compared with just using coffeescript)
- deleted 15y ago[deleted]
- huskyr 15y agoIt's nice that somebody like Crockford writes an article like this, telling us how to actually use the new syntax. The original ES Wiki article is probably great for browser vendors but i didn't quite get it the first time i read it.
- gfodor 15y agoAt this point it feels like the next version of Javascript should just standardize CoffeeScript syntax and add a few much needed features CoffeeScript can't currently do because of JS limitations.
- cormacrelf 15y agoIt sounds like people will prefer the (a,b) => {} syntax over function (a,b) {} simply because it's more concise and looks better, not because of its usefulness.
- darklajid 15y agoSometimes concise is (arguably, of course) better. Whenever I pass a simple and short function, for example as a predicate to grep/filter or as a tiny implementation for map/reduce I feel that "function" is half of what I type - and distracting. Worse, explicitly "return"ing adds more noise. Most of my anonymous functions are really, really small. If they are usually on the level of "d % 2 == 0" or "d.slice(42)" then removing the overhead of "function (d) { return" seems a good idea. Not a huge deal, but nice nevertheless.