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).
source maps can be the focus of the next release (probably 1.4.0)
Source maps in Firefox and Chrome will be one of the most important pieces of software infrastructure since Javascript itself. It will be the realization of Stallman's "one script to unite them all" vision for GNU GUILE from the "Tcl wars." A pity that it isn't Lisp, but there is enough goodness in Javascript (and Coffeescript) to make me very optimistic.
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)?
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"!
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.
I'll never understand the bytecode zealots and their insistence that browser makers scrap the years of JavaScript optimization they've done and start from scratch on some new format that will likely take another 10 or 15 years to get right.
You have what you want. You don't have to right in JavaScript any more. There are dozens of alternatives, and there are only going to be more. Source maps means you'll never even have to look at JavaScript. Please be happy!
Why should that "scrap years of JavaScript optimization"? That doesn't make sense. (Completely ignoring the fact, that JavaScript is not fast and will never be.)
Source-to-source-translation _always_ sucked and that's known for a few decades already.
> Why should that "scrap years of JavaScript optimization"? That doesn't make sense.
The bytecode that browsers compile JavaScript to are incompatible with each other. They would either have to pick one (wouldn't happen) or design one together (wouldn't happen).
A designed by committee bytecode would also effectively eliminate browser vendors' ability to compete on speed.
> Source-to-source-translation _always_ sucked and that's known for a few decades already.
In what way? From what I read Gambit Scheme compiles to C that is as fast as hand-crafted C. I would assume that CoffeeScript is no slower than regular old JavaScript. So if not speed, how are these things sucking?
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.
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.
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.
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!
I am not sure if this directly addresses your issue or not, but check out this reply to the article (1.3.1 just released to fix a problem undeclared globals and or= )
http://news.ycombinator.org/item?id=3824543
"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?
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.
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.
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.
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.
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.
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?
I can see that the parent comment was being a bit of a jerk, but why are all the comments in response (such as this one) being even worse? You could actually say something constructive in response instead of just resorting to personal attacks...
I say constructive things in response to constructive things, and am summarily dismissive of comments lacking substance.
Every time CoffeeScript is mentioned, there's always at least one comment like this. It's either trolling or people being closed-minded, but either way there's no sense in trying to have an actual discussion with someone who opens the conversation in this way.
If anyone would like to have a real debate on the merits of CoffeeScript, I'd love to participate, but the reality is it's largely a matter of taste.
This and debugging are my two biggest gripes about CoffeeScript. If you are saying this, then you probably never learned JavaScript to the extent that would be required to write what you are writing in CoffeeScript. Maybe that is a good thing and a testament to the power of CoffeeScript.
I am currently working with a bunch of people who don't understand functional scope nor closures (fully). They do, however, understand that sometimes they need to use "=>" for function declarations instead of "->".
Better you don't work with those people. I don't want to blame you for their lack of knowledge. But if you want to do them (and you and your project) some good, order them to learn JavaScript thoroughly (which includes the unexpected but regular features that deviate from other languages and the common pitfalls), and then go back to CS! CS inherits from JS and makes no sense without it and it fixes some pitfalls but just the ones that you can fix with the constraints and additions of a new grammar.
This is not the hard path but the only path to CS.
It's an important question, but one that many people have decided has a clear answer (in their judgement, for their own coding circumstances). In many cases, though not all, that answer is yes.
For me, it's similar to using a powered driver when assembling furniture.
Yes, there's added complexity. (Need to keep the battery charged; need to adjust the force dial to control how hard the screws and bolts are tightened).
But yes, dealing with that small bit of added complexity is worth it. (The furniture is assembled more quickly, more correctly, and with less irritation on my part.)
I could of course tighten all those bolts manually. But I don't wanna.
