
CoffeeScript 1.3.0 is out - pros
http://coffeescript.org/#changelog
======
jashkenas
For folks that are curious, we wanted to get these changes out the door --
strict mode syntax errors being a big one -- so that source maps can be the
focus of the next release (probably 1.4.0).

~~~
hcarvalhoalves
Regarding source maps... it feels like the solution to the wrong problem. Why
are we still pushing minified/obfuscated Javascript to the browser anyway?
What's wrong with standardizing on a bytecode format instead (e.g. JVM)?

~~~
chc
That's a bit like asking why I work out instead of snapping my fingers and
turning into a Greek demigod. One is clearly preferable on its own merits —
but it's just not going to happen any time soon.

Source maps are relatively easy: There's a public standard, a couple of
browser makers have agreed to it, and it doesn't need universal acceptance
since it's only for development. Basically, it doesn't require a lot of
coordination.

A universal bytecode is almost the exact opposite — easy to describe in the
abstract, but a coordination nightmare. I've never heard an actionable plan
for making it happen. Just getting the community to agree on a standard
bytecode would be a Herculean task†, and then you have to get Apple, Google,
Mozilla and Microsoft to all say, "Yes, I'm willing to chain my VM to this
bytecode at significant engineering expense."

Basically, feel free to work on this if you want, but you can't expect
everybody else to hold their breath until it happens.

† _You might think that "Herculean task" is an exaggeration, but just look at
how much discussion and compromise was needed to get agreement on stabby
function syntax for Harmony. And still people kvetched even once there was
"agreement"!_

~~~
soc88
With a common bytecode there would probably be a chance for languages to be
fast and not stuck with translations to JavaScript for the next decade.

~~~
chc
Citation extremely needed here. Bytecode isn't a magic speed potion — the
implementation is what will determine how fast it runs. For example, V8
ROFLstomps over the JVM-based Rhino JavaScript implementation.

At any rate, any bytecode the JavaScript VM people agreed to would almost
certainly correspond very closely to JavaScript, so it's not clear that a
standard bytecode would make alternative languages much faster. On top of
that, the optimizers in current JavaScript implementations are highly tuned
for JavaScript, so a bytecode-compiled program running on V8 might actually be
slower than the JavaScript we have today.

Basically, without an implementation, this all sounds like pie-in-the-sky talk
to me.

------
jashkenas
Oof. Embarrassingly enough, I just bumped us to 1.3.1 -- there was an overly-
strict patch that would prevent compound assignments to undeclared global
variables, like this:

    
    
        global.value or= 1
    

... which should now compile properly as expected.

~~~
TrevorBurnham
Looks like the REPL is still affected, though:
[https://github.com/jashkenas/coffee-
script/issues/1829#issue...](https://github.com/jashkenas/coffee-
script/issues/1829#issuecomment-5057522)

------
bryanh
Coffeescript is quickly becoming my favorite language for one little reason:
it gets out of my way and I just get things done. What more can you ask for?

My hats off to Jeremy and all the contributors. Thanks guys.

------
garindra
No IcedCoffeescript's await and defer integration yet? Will we ever see them
in Coffeescript's core?

~~~
jashkenas
First, the relevant thread:

<https://github.com/jashkenas/coffee-script/pull/1942>

It's not terribly likely that we'll see an IcedCoffeeScript merge soon, given
that the basic needs that a merge would entail haven't been addressed. A few
of them:

* We don't want to add helper libraries, like "iced.Rendevous", "icedlib.Pipeliner", or "icedlib.timeout" to our generated JS.

* Last time I checked, there was a significant slowdown even when compiling code that doesn't use "iced" features.

* For particulars on the grammar, @devongovett raises a number of worthwhile issues in the thread.

* There's still muddiness in the way that errors and exceptions are passed through the CPS transform.

* Some (important) edge cases like nested await blocks aren't handled yet, as far as I know.

... and so on.

~~~
maxtaco
Thanks for the 1.3 release, I was running out of lowercase letters. I'll try
to reply to these concerns in the pull-request, but have been busy. Also,
looks like I have rebasing work to do....

The good news is that ICS is working well in practice for us, we're still
really happy with it!

------
telemachos
Now that both _?=_ and _or=_ throw errors with an undefined variable, is there
another idiomatic way to write Ruby's _||=_ in CoffeeScript?

~~~
jashkenas
If you want the previous global behavior (make sure you're on 1.3.1) ...
explicitly say you're making a global:

    
    
        window._ or= require "underscore"

~~~
telemachos
Thanks.

------
JED3
"CoffeeScript now prints a Generated by CoffeeScript VERSION header at the top
of each compiled file."

From what I can tell there's no switch to optionally disable this? I can see
how it could be useful to keep unaware developers from making js changes in
compiled files, but other than that, what other purpose does this serve?

~~~
jashkenas
The most important thing it does is tell you _which_ version of CoffeeScript
was used to generate the file. Inevitably, as more and more coffee-generated-
JavaScript begins to wind up in more places, we don't want to end up in a
situation where you have to use trial and error, or distant memory, to figure
out which version to use to rebuild the JS.

~~~
Andi
This is not necessary since you usually add the CS version to your dev
dependencies (package.json). That should be enough. The resulting JS should
not show any reference to CS at all.

~~~
pilif
You assume coffee code running in the context of a npm-based package.

coffee can also be used in the browser using the Rails asset pipeline (where
you'd have the Gemfile, granted), or other methods (where you might have no
indication).

The only place where I would like this line not to be shown is when I try to
sneak coffee code into a codebase where only specific languages (JS in this
case) are allowed and all code has to be originally written in any of these
languages.

But honestly, if you are this devious, removing the line will be easy for you
and, secondly, even though the coffee compiler produces really nice JS code,
one glimpse is usually enough to recognize coffee compiler output as such, so
removing that one line hides nothing.

------
geraldalewis
Yay - strict mode early errors make CoffeeScript even more beautiful. Thanks
@jashkenas!

------
jamesflorentino
Nice work! I just wanna share that CoffeeScript has been pretty helpful to me
for rapid client-side JavaScript and NodeJS development. Much thanks to the
Jeremy and the CoffeeScript team.

------
TazeTSchnitzel
I've held out long enough. Now that I much better understand JavaScript (I've
read JavaScript: The Good Parts), I guess I should seriously give CoffeeScript
a try.

------
SagelyGuru
Great work!

------
bestest
Please forgive me for intruding the holyness of CoffeeScript, but I always
found and always will find CoffeeScript appaling and unusable. A wrapper for
otherwise syntactically and otherwise perfectly readable and codeable
JavaScript? Come on guys. Just learn JS, will you?

~~~
tombell
You're still coding in assembler I assume?

~~~
oscilloscope
Why do that when you already have perfectly readable patterns of bits.

~~~
TazeTSchnitzel
It's important to use zerospace to make your bits more readable! For instance:

    
    
        0010000
        0000110
        0000101
        0000100
        0011000

