- June 2014, Editorially complete (STH: we said June in the meeting, but July makes more sense, since we don't have to submit to the GA until September, IIUC)
- December 2014, ECMA approval
https://github.com/rwaldron/tc39-notes/blob/48c5d285bf8bf0c4...
Played around a bit with the generator functions and being able to replace straight callbacks with yields made the code so much cleaner and more readable.
Unfortunately, interoperability with callback/promise based libraries is a bit clunky.
Here's a talk my co-founder Alex gave on it: http://youtu.be/pmyDJnEza6A
Furthermore, where I work we do lots of high performance Javascript code and some of the conventions in the code CoffeeScript outputs is extremely wasteful when performing lots of calculations, such as calcing matrix multiplications per requestAnimationFrame. It simply produces far too many unnecessary expressions to evaluate. I would not be surprised if it reduces frame rate to half or a quarter of what you can achieve with pure JavaScript.
Yes, the JavaScript CoffeeScript produces often uses a more performant structure here and there than what many developers would naturally code. However most CoffeeScripters I've met have never really learned JavaScript well enough to understand how many cycles it throws away unnecessarily.
If someone writes CoffeeScript code that doesn't have to be fast, then more power to them for choosing a language they are happy with and feel productive. However, if they're writing a single page web app in CoffeeScript and wondering why it is dog-ass slow, CoffeeScript is going to be one of the contributing factors. It probably won't be the biggest factor, but it certainly won't be negligible.
Besides, I thought we were talking about server-side JS, where a native CoffeeScript implementation is a completely reasonable proposition.
[1] https://github.com/brixen/poetics [2] http://benchmarksgame.alioth.debian.org/u32/which-programs-a...