Closure Mode for CoffeeScript(bolinfest.com) |
Closure Mode for CoffeeScript(bolinfest.com) |
@jashkenas -- any thoughts/concerns with this? How likely is it to hit main branch?
If it were to happen, then yes, it should certainly be an option, though to clarify, you can use the Library without the Compiler, and the way things are written now, the only file from the Closure Library that your generated code would depend upon is the bootstrapping base.js file. (Though it may also depend on array.js down the road -- see the section "Leveraging More Closure Library Built-ins" on http://bolinfest.com/coffee/features.html.)
But I think it's completely fair to wait until it's "finished" before trying to upstream it, as Jeremy suggests. It will likely take a bit of refactoring for the CoffeeScript code to support "plugins" such as these. As you can see, I'm just spraying "if o.google" statements in https://github.com/bolinfest/coffee-script/blob/master/src/n... to get things done right now, which would not be acceptable to upstream in its current form.
I've been writing some of my latest stuff in strict mode style and it's kind of a burden to keep track of what you can and cannot do (plus the code is fairly ugly). I'd love to be able to just write in CoffeeScript and know I'd be compatible. (Personally less interested in using Closure as a library, but still cool that the work is being done).
http://www.sitepoint.com/google-closure-how-not-to-write-jav...
Whatever you might think about Closure, please do not make up your mind about it from this article. The author does not seem to be an experienced javascript developer (at that time).
EDIT: wording.
As this would greatly help the closure compiler do optimisations, and since it is opt-in to add the typed parameter and would only produce a javascript comment above said variable.
For example....
foo <: String = "hey"
/* @type {String} */ var foo = "hey"
I don't think this is deviating from CoffeeScript's aim to keep things pure? Is it?
That said, statically marking your variables with "types" (where types are incredibly weak and limited in JavaScript) isn't going to be of much use to you, performance-wise. Modern engines like V8 already unbox local variables where possible, and do "hidden class" analysis to give a "type" even to regular unstructured JS objects.
Thanks anyways though