Does anyone know when ECMAScript6 (Harmony) is supposed to be finalized? The last I heard is December 2013, which is this month... wondering when all of the harmony features that are in node 0.11 are going to make it to the stable releases?
- 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)
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.
Ick! No thanks. It produces the ugliest, most obtuse javascript code I've seen.
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.
It sounds like you actually have done some benchmarking and understand the places it really is necessary to get to the bare metal. Many forget that most code doesn't have to be that fast (see: premature optimization). Much better to save developer cycles.
Besides, I thought we were talking about server-side JS, where a native CoffeeScript implementation is a completely reasonable proposition.
True, however even the server-side CS code gets compiled to JavaScript before execution by node.js. At least with the server though, you can enjoy the benefit of throwing more servers at the problem or you can write high-performance code in optimized C.
There's no reason server-side CoffeeScript must be compiled to Javascript, that's just the most common example. There are native implementations, like Poetics [1]. And note that high level languages are starting to really encroach on C's performance crown [2].
Curiously though, CS still doesn't support yield despite there being solid PR's, no matter how many times I thrash the refresh button on the github's issues page.
