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.
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"!
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!
Source-to-source-translation _always_ sucked and that's known for a few decades already.
>But why is this REALLY COOL? Because I can potentially debug any language in the browser as long as it has a source map.
global.value or= 1
My hats off to Jeremy and all the contributors. Thanks guys.
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.
The good news is that ICS is working well in practice for us, we're still really happy with it!
window._ or= require "underscore"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?
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.
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.
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 "->".
Wait, are you being sarcastic?
Whether the difference in usability and maintainability is worth the extra layer of complexity is an important question.
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.
0010000
0000110
0000101
0000100
0011000