Book Review: CoffeeScript: Accelerated JavaScript Development 100
Michael J. Ross writes "For decades, programmers have written computer code in one language, and then programmatically translated that code into another, lower-level form (typically machine code that can be run directly by a microprocessor, or some sort of bytecode that can be interpreted by a virtual machine). For instance, source code written in C or C++ is compiled and assembled into machine code. In web programming, there are emerging languages and other tools for translating code into JavaScript. For instance, Google Web Toolkit allows the programmer to create web apps in Java. The latest addition to this category is CoffeeScript, a language that can be compiled into JavaScript, and is intended to reduce source code size and clutter by incorporating some of the best operators from other Web scripting languages, particularly Ruby. It is also the topic of a new tutorial, CoffeeScript: Accelerated JavaScript Development." Read on to learn what Michael thinks of this book.
This book is authored by Trevor Burnham, who is credited as one of the early contributors to the project by Jeremy Ashkenas (the creator and project lead of CoffeeScript) in his foreword to the book. Published by Pragmatic Bookshelf on 3 August 2011, under the ISBN 978-1934356784, CoffeeScript: Accelerated JavaScript Development fills only 138 pages, which is certainly a change of pace from the majority of programming tomes now being released. This book's material is grouped into six chapters, plus four appendices — aside from a preface, which introduces CoffeeScript as well as a word game, which is used as the example project throughout the book. Oddly enough, the preface mentions jQuery, but not as one of the well-known attempts to streamline JavaScript code.
| CoffeeScript: Accelerated JavaScript Development | |
| author | Trevor Burnham |
| pages | 138 pages |
| publisher | Pragmatic Bookshelf |
| rating | 5/10 |
| reviewer | Michael J. Ross |
| ISBN | 978-1934356784 |
| summary | A fast-paced tutorial of CoffeeScript. |
The first chapter, "Getting Started," begins by briefly explaining how to install Node and npm (Node Package Manager). These instructions assume that you are following along in a Linux environment or some emulation thereof. They also seem to assume that nothing goes wrong in any of the steps, because no troubleshooting guidance or references are provided. Given the number of moving parts required to get CoffeeScript running, as well as the technical pitfalls that could ensnare a Windows or Mac user, the author should have provided more clear and detailed installation instructions. Also, readers unfamiliar with Linux/Unix may be puzzled by some of the instructions. For instance, page 3 appears to state that the way to check that those two aforesaid packages are on your path, is to simply type in "PATH" (whereas what is needed is "echo $PATH"). From that point forward, the narrative gradually becomes more opaque, with cursory coverage of text editor plug-ins, the "coffee" command line compiler, REPL, "the soak" (an existential chain operator), and the limitations of trying to debug CoffeeScript code. It is quite possible that by the end of this chapter, many readers will decide to not bother trying to learn CoffeeScript, and instead to stick with plain JavaScript, possibly supplemented with jQuery (which is not to say that jQuery code is any easier to read).
In the next three chapters, the author presents the basics of CoffeeScript, including how to: define and use functions and their arguments; test conditionals; throw and catch exceptions; understand variable scoping and context; create arrays using splats; accept input from the console; create objects, arrays, and soaks (in more detail than before); iterate over collections; match patterns; define namespaces using modules; and create prototypes and classes. He makes extensive use of examples, which thankfully are concise (unlike some programming books whose example code span far too many lines, and sometimes even multiple pages — forcing the reader to dig through the code, trying to find the important lines). Also, the brevity of CoffeeScript syntax is undoubtedly a factor. However, his concise style extends to the narrative as well, and will likely cause newbies to have to read the material several times — and even then wonder whether they fully grasp the concepts. It seems that the author understands CoffeeScript extremely well, but is not always able to communicate that knowledge to the reader in a patient and comprehensible manner.
Chapter 5 is a primer on jQuery, and is apparently included in the book so that the example application (the word game) can be made to work in a web browser — since none of the code or narrative (aside from the example app) appears to be related to CoffeeScript. It would have been more efficient to simply point the reader to an online jQuery tutorial, and then present only the CoffeeScript-specific differences — or just briefly explain how to load CoffeeScript files in an HTML file, which could have been done in a sidebar. The last chapter demonstrates how to run CoffeeScript on a web server, utilizing Node.js, and also explores how the lack of threads in JavaScript can impact Node programming. The example project is made multiplayer using Node, Connect, and WebSocket.
The appendices provide answers to the end-of-chapter exercises, alternative methods of running CoffeeScript code, a JavaScript cheat sheet, and a list of a half dozen bibliographic references. This book concludes with a suspiciously-short index, at less than three pages long, which appears to provide only the first or earliest occurrences of the major terms. Consequently, anyone who tries to use this book as a reference work for looking up key terms quickly — or for finding their later occurrences — will likely need to obtain an electronic version of the book, since all e-readers have search functionality. Furthermore, the index is missing some key terms used in the text, such as "function callbacks" and "arbitrary expressions" — heck, it's even missing "expressions," a fundamental concept in any programming language.
Prospective readers who wish to learn more about the book, can visit Pragmatic Bookshelf's page, which offers brief descriptions of the book and its author — as does O'Reilly Media's page. But, as of this writing, only the former makes available an e-book version, pre-publication reader comments, a discussion forum, the example source code used in the book, and a link to a page for reporting errata, which already has more than half a dozen items listed. More are present in the text: "add [a] multiplayer capability" (page xx); a lone ")" missing its matching "(" (in Exercise 6, page 34); "in a lot in functions" (page 107; should read "in a lot of functions"); "a[n] overhead" (page 110); "everyone and their dog is" (page 116).
The author's writing style is sometimes quirky, which in most cases adds a bit of levity, but occasionally leads to the misuse of terms, e.g., array ranges usage described as "fantastical" (page 43). "BDFL" (page xiii) will prove puzzling at first to most readers. On page xvi, the reader is told that JavaScript "contains multitudes." — multitudes of what? And nothing can excuse the groan-inducing "automagically" (page 100).
In terms of the ordering of the topics, one of the most exasperating aspects of this book is the way that many language concepts — such as chained comparisons, and variables being true or false (or "truthy" or "falsy") — are not presented up front, on their own, but mixed in with discussions of other topics, including development of the game application, and even in the answers to the chapter questions (Appendix 1). This makes the book generally unsuitable as a reference, especially when combined with a disappointing index.
One might assume that the modest size of this book is a result of the small size of the language itself. But another factor is surely the pithy presentation style for even some of the most important concepts in the language. Perhaps worst of all — especially from the perspective of someone relatively new to programming — some basic concepts are not addressed, or the example code does not address common use cases. For instance, in CoffeeScript, how does one create a block consisting of multiple lines of code? On page 17, indentation is briefly mentioned, but the sample code shows single-line blocks only. Other important ideas are "saved as an exercise" (which may induce flashbacks to exasperating technical college textbooks). Some readers may conclude that the author didn't want to make the effort of fully describing the language, in a more canonical fashion, which would have resulted in a much longer, but more valuable book.
It is unclear as to how much of the likely mystification and frustration of the average reader will be due to the writing choices made by the author, and how much can be blamed on the sometimes cryptic syntax of CoffeeScript, evident in the discussion of topics such as function binding (Chapter 2) and keywords (e.g., from page 106, "what.x and @x are, of course, equivalent if and only if what is this." Of course!). Readers are told in the introduction that they do not need to be experts in JavaScript to understand the book's material, and can be amateurs (page xviii). But there are several places in the book where intermediate-level knowledge, at a minimum, would be needed. That sort of difficult material may be another point in the CoffeeScript journey where some readers will decide to eschew learning the language.
The production quality of the book is fine, except that the chosen font's ratio of height to width is more than what is usually found in books nowadays; when combined with inadequate spacing among the words within many of the sentences, it makes it difficult for the reader to rapidly scan the material. The e-book version reflects the same minor problem. Yet it makes excellent use of color for syntactically highlighting the code — a feature not seen in the print version.
So if you would like to do some JavaScript programming, but without writing any JavaScript, then one possible place to start your journey is CoffeeScript: Accelerated JavaScript Development. As of this writing, it is the only CoffeeScript book on the market. Yet should the language continue growing in popularity, then more substantial and recommendable books will probably become available.
Michael J. Ross is a freelance web developer and writer.
You can purchase CoffeeScript: Accelerated JavaScript Development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re: (Score:2)
Re: (Score:1)
I think he's trying to say why do you need an additional wrapper when JQuery makes it really easy on its own? Specifically isn't it pointless to write JS in ruby when you're not using ruby anyhow? Why bother learning another language just to write javascript.
Re: (Score:2)
CoffeeScript isn't really a whole other language. It's Javascript, but with a new and -- arguably -- nicer syntax. There's an awful lot more to a language than syntax. Syntax is one of Javascript's weakest areas.
Why do people choose Javascript? Not, generally, because it's a beautiful language. More because it's the only language natively available for manipulating the DOM in a browser.
Node.js is an interesting rebuttal to that argument. It seems to be very popular, despite there being plenty of alternative
Re: (Score:2)
The only thing I find wrong with it is that its seeming similarity to Java and C# makes it easy to expect something in JavaScript to act like something in C#.
Re: (Score:2)
Without being too exhaustive...
When written in the Crockford-approved idiom, I find it awfully verbose:
... }
MyClass.prototype.myMethod = function (x,y) {
When working in a functional style (and it would be a shame not to) I find bracket management terribly fiddly. It's common to find yourself struggling with ')})});' -- it's worse than LISP, since at least with LISP all the brackets are of the same type!
But mostly, it's a subjective feeling that there's a load of punctuation and fluff on screen that gets in
Re: (Score:2)
Parentheses and white spaces alone do make some magically readable code once you become accustomed to it.
Re: (Score:2)
I did not for one second intend to demean LISP.
Re: (Score:2)
Re: (Score:2)
Think of CoffeeScript as a Javascript generator. You can generate any JS with it, including JS that calls qooxdoo, or whatever you like.
You can even embed literal Javascript, although I've never needed to do it.
Re: (Score:2)
I don't consider it an improvement. Maybe if you get a hard on for ruby or python.
Subjective, ain'tcha?
Re: (Score:2)
To be fair, being hackish is a requirement of being cross-browser. At least you don't have to write hackish code yourself when using jQuery, everything is more likely to "just work" with a few exceptions.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
What's wrong is that jQuery is NOT CoffeeScript. In the computer science world, someone (must) come along to invent a new language to satisfy his own inflated ego. If I take a wild guess, I'd say that behind all the mumble jumbo, putting his name on a language, and eventually publishing a book about it is the real motivation.
You might claim that Ruby is the product of an inflated ego, since it postdates Python. Or that Guido's egotism was what led him to create Python, rather than us all stick with Perl. I would disagree with you -- but at least it wouldn't be a nonsensical claim.
But CoffeeScript is not an attempt to supersede or replace jQuery. CoffeeScript is a compiler that produces Javascript. jQuery is a Javascript library for DOM manipulation and event processing.
CoffeeScript and jQuery happen to complement each other ver
So who will write ExpressoScript? (Score:2)
And then who will write ExpressoScriptDoubleShot?
Re: (Score:2)
Re: (Score:2)
I'm waiting for Americano...
Now I'm going to have to break out the Campari and Cinzano.
My evening is shot and it's all your fault!
Re: (Score:2)
Shouldn't that be LatteText? Or MaccchiatoSculpt?
Re: (Score:1)
Re: (Score:2)
debugging (Score:1)
It must be such a joy to debug programs written in these higher level languages. Especially on internet explorer, where error messages are practically meaningless.
Re: (Score:1)
It's actually pretty easy; CoffeeScript is almost a line-for-line translation to JS, so it's easy.
It more than pays off for itself with its terse syntax for routine tasks in JS, like defining functions and re-binding callback functions in the current contexts, something jQuery actually makes less intuitive.
And the code is a LOT more legible.
Re: (Score:2)
Hell, yeah.
I've been writing with Coffeescript, HAML, and Stylus for about a year now, and I'm not looking back. Most IE-specific errors these days are parser errors rather than semantic errors, so JS-Lint takes care of that. And you can't use Coffeescript without knowing Javascript, you just can't; too many libraries are written in JS for you to be unable to read them. And Coffeescript has a node.js mode that rocks.
Re: (Score:2)
it's an interesting little language but it's syntax when doing callbacks could be cleaner and it's return policy is not so fun in node.js
Odd. I find it very convenient for callback based programming, especially in Node.js. Lots of Node programmers use CS.
I was experimenting with stream processors with a functional-programming flavour.
wc = new InjectStream 0, (acc, line) ->
acc + line.split(' ').length
emits the JS:
wc = new InjectStream(0, function(acc, line) {
return acc + line.split(' ').length;
});
It tends to be nice and neat, as long as the callback is the final argument -- which is usually the c
Re: (Score:2)
I personally find all those '});' -- and worse -- bracket clusters in JS and Java, distasteful.
I find Python-style semantic indentation distasteful. So here we are.
yet another language (Score:1)
Just what we need.
Re: (Score:1)
Re: (Score:3)
It's frustrating. I work with jQuery/JavaScript daily.
Same here. I don't understand why people think that JS is so bad that it's actually better to write in another language and have the JS automatically generated. From C to Assembler the choice is obvious, but JS is already not terribly difficult to use, especially with the libraries available today.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Partly because JS is just not nice to look at, and partly because there's just so many ways to do something in JS, it makes it hard to collaborate on a project. Look at constructors for example. CoffeeScripts solution is to take the return value of when an anonymous function calls itself and assign that to a variable. I'm sure there's a good reason why it's done that way but it really drives me crazy to have to look at code like that.
Re: (Score:2)
Re: (Score:2)
If you already know Javascript, I reckon it'll take you less than 3 hours to learn CoffeeScript.
The brief documentation at http://jashkenas.github.com/coffee-script/ [github.com] , is pretty much all you need. On the same page, you can type CoffeeScript in, and see the generated JS. You'll be there in no time.
COBOL calls you. (Score:2)
Just what we need.
That's what our COBOL forefathers used to say. Seriously, I will never understand why people who make their careers in software decide to make statements like that. Yes, there are always problems with language proliferation, but the alternative is stagnation. We always know more about how to make better software over time, and that inevitably brings changes in tools, languages and paradigms. And you cannot foreseen how much variation is too much (or too little) after the fact.
If there weren't people pushi
I have one better (Score:1)
I have developed even a better computer language, here is the syntax:
this is the output:
Re: (Score:2)
Re: (Score:1)
I bet he is lying about his heritage.
Re: (Score:2)
I give any js task to my nubile red headed Scandinavian assistant ...
That red hair has gotta come from a bottle, because everyone knows that Scandinavians are all blond(e).
Maybe (s)he's actually Irish or Scottish, and just pretending to be Scandinavian?
(I have ancestors from all the above areas, so I can get away with mocking the stereotypes of all of them. I couldn't find a way to also mock my French ancestors in this reply, but maybe next time ...)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Eh, I must be new at this. My input looks the same:
But the result is this:
Re: (Score:1)
You just want the wrong thing, it's a nube thing.
Uphill both ways in the snow. (Score:1)
Re:Uphill both ways in the snow. (Score:4, Informative)
I felt the same way until I went to a local coding dojo and they had chosen Coffeescript as the language that week. 2 hours later, I'm a convert. Seriously, it's pretty nice, if for nothing other than dealing with classes in a sane and safe way.
One of the things they said that convinced me was that the javascript it outputs is much, much better than the equivalent javascript you'd write by hand. And I have to agree... it was very thorough and complete.
Re:Uphill both ways in the snow. (Score:4, Interesting)
Re: (Score:2)
Can you expand on that point about variable scoping please?
My perception is that CoffeeScript does the same as Javascript, except that globals are harder to create (good!)
The JS generated by CoffeeScript pushes variable declarations to the top of the function, so it's clear what the scope is. That's a real gotcha for JS newbies.
Re: (Score:2)
Maybe he means http://jashkenas.github.com/coffee-script/#lexical_scope [github.com] ?
Some discussion on why it could be bad: https://github.com/jashkenas/coffee-script/issues/712 [github.com]
Personally, I tend to use classes extensively, so this is a lot less likely to happen. (Because you need to use "this." or "@" for class variables.)
Re: (Score:2)
I really wonder when in time the meaning of "extensiv(ly)" changed that so many people use it liek you do. In other languages, like german extensiv is used as the opposite of intensiv. In fact the word extensive is rarely used but e.g. in agriculture you would say intensive agriculture, meaning you use a relatively small area and irrigate it and use fertilizer e
Re: (Score:2)
In the common usage, "extensive" means "having a large extent".
In agriculture and physics, it can be used as the opposite of "intensive", but it would only be understood among subject expert peers.
Re: (Score:2)
Re: (Score:2)
2. Super-easy, but hard to understand, and errors are not picked up at compile time (C, Perl, PHP, Javascript)
C does not belong in that list....
What needs to happen is that these upper-most languages need to "flatten the layers" to use a photoshop analogy, down to just a CPU/GPU-neutral LLVM JIT compiler. This isn't what happens now.
Except in .NET... All .NET languages compile down to an IL, which is then compiled by a JIT on the platform it is run on....
Re: (Score:2)
Re: (Score:2)
In the "irrelevant" pile since nobody uses them outside the university.
Re: (Score:2)
Most people don't want to learn things for their own sake, they want to get something done and learn just enough to accomplish that.
Thanks, but no thanks. (Score:1)
It also makes it 100x harder to track down problems because you're not writing the code in the same language as what it is compiling in to. Trying to guess what line number reported by a browser lines up in your coffee script is going to be a real pain in the ass, especially in larger scripts.
Re: (Score:2)
Debuggers have been handling this for decades already. You just embed the original line numbers in the generated source.
Someone is bound to write that debugger plugin, if they haven't already.
Re: (Score:2)
In practice, it's not that hard.
When you're debugging, you debug Javascript. Then you figure out what part of the CoffeeScript generated that Javascript. This tends to be straightforward.
To be sure, it's a negative. But it's vastly outweighed by the legibility of the CoffeeScript, how much faster it is to write, the code quality it engenders.
Isn't this a worse solution ? (Score:3, Insightful)
Re: (Score:1)
I thought the problem with javascript was it was weakly typed , dynamic and not typesafe.
I agree with you... But I have friends who argue that those exact problems are actually its strengths. It boggles the mind.
Re: (Score:1)
in 15 years of coding javascript, I can't say that I've run across any serious problem caused by dynamic typing, even on large codebases (80,000+ loc). JavaScript is extremely predictable once you know how it works. The people who hate dynamically typed languages can't grasp why it isn't the clusterfuck they think it is, so they always put down JavaScript for something they don't know how to deal with.
Re: (Score:2)
But the biggest frustration for me with JavaScript is that, as implemented in web browsers, trying to simple test datatypes and null objects is a major exercise in frustration.
Coffeescript:
solipsism = true if mind? and not world?
emits the Javascript:
if ((typeof mind !== "undefined" && mind !== null) && !(typeof world !== "undefined" && world !== null)) {
solipsism = true;
}
(example taken from the CS homepage)
someone really needs to clean up JavaScript itself
I think the JS community is united in recognising the defects JS has. What's recognised is that the install base is there, and if you want to develop for real people with real browsers, you're stuck with it. Crockford has done a great job
Re: (Score:2)
I thought the problem with javascript was it was weakly typed , dynamic and not typesafe so it was very hard to maintain a really large javascript project.
For the second time this week, I find myself arguing that strong static typing is not something that particularly helps you with large projects. If you write something big, you should be modularising it, and type mismatches aren't easy mistakes to make when communicating between modules.
No, strong static typing is most useful when you're writing the small, detailed, bit-twiddling parts of your code.
Fortunately, that kind of work is seldom what you're doing in Javascript.
Re: (Score:2)
JavaScript is not weakly typed, it is dynamic typed, yes but still strong typed.
Response from the author (Score:2)
Re: (Score:2)
Syntactic sugar (Score:3)
CoffeeScript doesn't actually do much; it's just another syntax for writing Javascript. Javascript is an OK language, Not a great one; it suffers from some of the standard mistakes.
A classic error is thinking you don't need declarations, and then having to retrofit them. This usually leads to ugly problems, especially if declarations are optional, because the defaults will be backwards. There's a long history of this, starting with FORTRAN and continuing through BASIC and C. Python is almost the only language to successfully work without declarations.
Syntax matters! (Score:2)
Then again, any language is just another syntax for writing Assembler.
Re: (Score:1)
Don't stop there. :)
Assemler too is a kind of syntax sugar for writing machine code. isn't it?
And machine code is a kind of 'syntax' so you dont have to make special circuits for everything you want it to do, right?
Re: (Score:2)
Re: (Score:2)