Hmm, I'm afraid it's a bit late to add another project to the book (there is a Node project, but it doesn't use persistence), so how about if I write this and post it somewhere else? Would you prefer MySQL or MongoDB?
I was planning to post this link later, when the book becomes available. I can't share any details yet, but look for an announcement next week. I run @coffeescript on Twitter, so you'll definitely stay updated if you follow me there.
Many of those tools (including Coco, a CoffeeScript fork which is, objectively, more feature-rich) provide features to help manage asynchronous control flow (that is, to make callbacks look more like linear code). These proposals were rejected in CoffeeScript (see https://github.com/jashkenas/coffee-script/issues/350) because they take the language too far away from the underlying JavaScript—in particular, CoffeeScript code would no longer necessarily have the same order as the JavaScript output.
For heavily async code, those other tools are well worth looking at.
So here's a related question. If someone wanted to snag a developer that really understood coffeescript and js development, where should they be looking?
Someone who really understands js can pick up coffeescript in a few hours, so don't pass on a good js developer just because they haven't yet made the jump.
I don't completely agree -- I feel like CoffeeScript shares as much in common with Ruby and Python as it does with JS. I'd say a good developer would be the best fit for a CS position; depending on your deployment platform, I can almost see a case where being an embedded JS programmer might actually cause issues. If all you understand is EcmaScript, all you'll write is EcmaScript. Despite its tagline being "It's just JavaScript", it's actually much more.
I knew Python and Ruby before I started with CoffeeScript, so perhaps that colored my experience. CoffeeScript is basically a minimalized blend of js, Ruby, and Python syntax-wise. But I still think someone who understands js will pretty much automatically get CoffeeScript concept-wise, at least to the level they get js concept-wise, because the central concepts of programming in CoffeeScript aren't different than js, just the syntax.
Could try jobs.github.com. Coffee script will also be a semi-default in Rails 3.1. A Ruby and good JS person should be able to pickup CoffeeScript in a few hours though.
This is really great to see -- correct me if I'm wrong, but Trevor must be one of the biggest contributors to CoffeeScript. It's great to have someone so intimately familiar with the project author one of its first books.
Code-wise, I'm only a minor contributor to CoffeeScript. I wouldn't be the right person to write a book on how the CoffeeScript compiler works. (Thankfully, some of those people agreed to be technical reviewers for the book.) But I have been an active participant in the language's community from early on.
Criticisms welcome. We're aware of some technical issues (most notably, there's no syntax highlighting for the CoffeeScript snippets), which will be fixed shortly.
Unfortunately, it isn't really possible to understand CoffeeScript without understanding JavaScript, so it's not a very good choice of first language. JavaScript is. So, the book assumes at least a beginner-level understanding of JavaScript.
I have to disagree with you there. As there is a 1-to-1 mapping between CoffeeScript and JavaScript, I'd say that they are equally hairy first languages but the former has nicer syntax. The beginner documentation and workflow just isn't there with CoffeeScript yet.
I'm actually not totally sure why you say that it isn't possible to understand CS without knowing JS. Is it because CS compiles to JS? If that's the case, I'd point out that you definitely don't have to know bytecode to learn Java.
Well, the "JavaScript is the new bytecode" analogy only goes so far. JVM bytecode puts few limits on what your language can do efficiently—Java, Scala, and Clojure, for example, all have great performance, despite having very different idioms. CoffeeScript, on the other hand, was clearly designed around what you can do with JavaScript. Or more precisely, what you can do while 1) producing predictable, readable, 1:1 output, and 2) getting good performance. So I think CoffeeScript is best understood in light of those limitations.
Plus, learning CoffeeScript wouldn't be much use if the docs for every JS library read as gobbledygook, right?
Yeah, I guess I was overreaching with my argument about bytecode. But, we can probably agree that it's more enjoyable to focus on writing good CoffeeScript than on writing CoffeeScript which will compile to good Javascript. Regarding the libraries, couldn't the same be said about learning Clojure without knowing Java (something which I think would currently be pretty acceptable)?
All I'm getting at is that I'd like to see CS eventually become a language in its own right rather than an extra tool for JS developers. I think this is completely feasible if we start treating it that way and create the tools and documentation to that end. I think it is a serious improvement over JS and could eventually replace JS for the common programmer.
By the way, thanks for all your work, I'll definitely be picking up the book.
> All I'm getting at is that I'd like to see CS eventually become a language in its own right rather than an extra tool for JS developers.
Yeah, totes. Brendan Eich himself has assured me that the Mozilla folks are dedicated to adding debug support for CoffeeScript (and other compiled JS languages) to Firefox. So the underlying JS will be less and less of a concern as the tools get better.
At the same time, though, that'll probably lead to languages that go further than CoffeeScript taking hold, just as Clojure is rockin' it on the JVM despite being really far removed from Java. I like CoffeeScript a lot, but when JavaScript really does become bytecode, people will want to code in something less JavaScript-like. (Or CoffeeScript may become the new C... "assembly with syntax," in pg's words.)
Asm/C and Java/scala are unfair comparisons, since they're totally different languages with different structures and idioms.
I just started using CoffeeScript for a project of mine and while it did clean up the messy look of the Javascript, it doesn't improve much upon Javascript feature-wise. I felt like I was still writing Javascript, it just looked a little better.
I've been writing CoffeScript daily for about 4 weeks now. On the first day, it seemed pretty minor. About three days in I was a believer. Now, when I write the occasional few lines of Javascript in my browser's console, it just feels so arduous to type. Whenever I pop open a Javascript library to read it, I feel like there is an assault on my eyes. I'm never going back.
It looks a LOT better, it requires a LOT less typing, and it saves you a LOT of stupid syntax errors and typos compared to brace-semicolon-comma-parentheses stew.
This is the only comparison on your list that is remotely appropriate. In no meaningful way is it true that
CoffeeScript:Javascript :: C:Assembler
Javascript is not a low-level language resembling a primitive machine interface, and CoffeeScript mostly provides syntactic sugar, not new semantics or a different paradigm.
Javascript is not a low-level language resembling a primitive machine interface, and CoffeeScript mostly provides syntactic sugar, not new semantics or a different paradigm.
In order for A:B :: C:D it is not the case that A and C need to be similar, nor B and D.
The comparisons made in the GP have very little in common. The Java:Scala distinction is not similar to that of ASM:C, and neither has a similar relationship to that of HAML:Erb. So there are many objections that can be made to the analogy, especially that the analogous relationships provided are not even analogous to each other!
The sentence you quoted makes some assumptions of the reader's knowledge, namely that the reader understands "syntactic sugar" to be a process of trivial, linear transformation. The basis of the objection is not that Javascript is unlike ASM; the objection is that the relationship between Javascript and CoffeeScript is between a high-level scripting language and a trivial transformation layer of that language.
On the other hand, ASM is a low-level interface and C is a paradigmatic shift (comparatively) in programming that introduces semantics which are divorced (to an extent) from their machine implementations.
That relationship is not analogous to Javascript:CoffeeScript, as it is not nearly as significant.
