9 ms·
CoffeeScript 1.3.0 is out
- jashkenas 14y agoFor 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).
- stcredzero 14y agosource 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.
- ahrjay 14y agoNice source map support will be huge.
- hcarvalhoalves 14y agoRegarding 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 14y agoThat'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 14y agoWith 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 14y agoCitation 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.
- MatthewPhillips 14y agoI'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!
- soc88 14y agoWhy 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.
- MatthewPhillips 14y ago> 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?
- lucian1900 14y agoFurthermore, some engines don't even have bytecode or even an interpreter and directly generate machine code (V8).
- hendzen 14y agoThis is in the works already with Google's PNaCl. I believe the bytecode format is based on LLVM IR.
- chc 14y agoAFAIK, PNaCl is heavily deemphasized in favor of vanilla NaCl.
- eloop 14y agoJVM in the browser had wide adoption and plenty of resources behind it, and failed miserably. Why should we try it again ?
- christiangenco 14y agoFor folks that had no idea "source maps" was a meaningful term, http://css.dzone.com/articles/source-maps-coffeescript http://css.dzone.com/articles/source-maps-coffeescript
- messel 14y ago>Why is this cool? Because I can debug CoffeeScript in the browser! <insert Kool Aid man "OH YEAH!" here> >But why is this REALLY COOL? Because I can potentially debug any language in the browser as long as it has a source map.
- shaundunne 14y agoI might actually get some fellow devs to start accepting CoffeeScript after my 6 months of hounding them.
- SagelyGuru 14y agoGreat work!
- bryanh 14y agoCoffeescript 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 14y agoNo IcedCoffeescript's await and defer integration yet? Will we ever see them in Coffeescript's core?
- jashkenas 14y agoFirst, the relevant thread: https://github.com/jashkenas/coffee-script/pull/1942 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 14y agoThanks 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 14y agoNow that both ?= and or= throw errors with an undefined variable, is there another idiomatic way to write Ruby's ||= in CoffeeScript?
- jashkenas 14y agoIf 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 14y agoThanks.
- wc7 14y agoI 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 http://news.ycombinator.org/item?id=3824543
- jashkenas 14y agoOof. 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 14y agoLooks like the REPL is still affected, though: https://github.com/jashkenas/coffee-script/issues/1829#issuecomment-5057522 https://github.com/jashkenas/coffee-script/issues/1829#issue...
- JED3 14y ago"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 14y agoThe 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 14y agoThis 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 14y agoYou 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.
- flywheel 14y agowow, the insanity continues.
- bestest 14y agoPlease 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 14y agoYou're still coding in assembler I assume?
- oscilloscope 14y agoWhy do that when you already have perfectly readable patterns of bits.
- TazeTSchnitzel 14y agoIt's important to use zerospace to make your bits more readable! For instance: 0010000 0000110 0000101 0000100 0011000
- deleted 14y ago[deleted]
- bct 14y agoThe difference between assembly and (for example) C is vast. The difference between JS and CS is much smaller. Whether the difference in usability and maintainability is worth the extra layer of complexity is an important question.
- veidr 14y agoIt'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.
- geraldalewis 14y agoYay - strict mode early errors make CoffeeScript even more beautiful. Thanks @jashkenas!
- TazeTSchnitzel 14y agoI'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.
- jamesflorentino 14y agoNice 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.
- deleted 14y ago[deleted]