Ambiguous Code

I quickly found that there were situations where I couldn’t predict what a given chunk of CoffeeScript would compile to or couldn’t figure out how to write the CoffeeScript for the JavaScript I wanted. The problem arises because in CoffeeScript parenthesis, curly braces and commas are often optional and white-space and indention replace them. Frequently code I thought should compile didn’t. Consider this valid code.

func5,{event:->45,val:10}

Now, if the event function needs to be expanded, one would logically think it could be changed like this.

func5,{event:(e)->ife.something36else45,val:10}

However, that doesn’t compile. You have to drop the comma or move it onto the next line, beforeval.

How about something likefunc1 1, func2 2, 3? Does 3 get passed to the first or second function? I still frequently forget one place where parenthesis are not optional, leading to unexpected behaviour. The statementx = f -> f looks like it should assign x to the identity function, but it doesn’t. Instead, x is assigned the result of calling f with a function of no arguments returning f. Or how about this,a + b adds a and b whilea +b calls a with the argument+b. There are lots of other examples of ambiguous and confusing syntax in CoffeeScript. For more examples, check outMy Take on CoffeeScript by Ruoyu Sun and thisGist from Tom Dale.

Readable, Think Again

Ambiguous code is only one part of what makes CoffeeScript difficult to read. Everything is an expression (returns a value) and it has lots of control flow and operator aliases. All of which encourages very English sentence like code. However, that often makes the code less readable, not more. The human mind is good at understanding logic in symbols; English is not good at expression logic. As an example, consider the lineeat food for food in foods when food isnt 'chocolate' from theCoffeeScript tutorial. The declaration of what food is occurs in the middle of the line and doesn’t even look like a variable declaration. Furthermore, until you finish reading the line it isn’t clear which foods will be eaten. That code could easily be worse ifunless eat is undefined was added to the end, making the whole line conditional. One wouldn’t realize it was conditional until reading the end. Imagine if the expression before thefor had been a complex multi-line method call with logic in it. Ryan Florence digs deeper into these issues in his postA Case Against Using CoffeeScript. Suffice it to say, many of the features added to CoffeeScript with the intent of making it “readable” actually have the opposite effect.

Variable Capture

In addition to the these confusions, CoffeeScript actually creates new mines that aren’t present in JavaScript at all. As explained by Jesse Donat inCoffeeScript’s Scoping is Madness, in CoffeeScript’s zeal for terseness and “simplicity” it has actually created a major pitfall around variable declarations. In CoffeeScript there is no variable declaration syntax equivalent tovar in JavaScript. Instead, all variables are declared in the scope they are first assigned in. This means it is easy to accidentally change the scope of a variable and not even realize it.

To see how this would happen, imagine you are in a hurry to implement the next feature. Unbeknownst to you, the following code is near the bottom of the file you are about to modify.

innocent=(nums)->lastValue=1fornuminnumsdoSomethinglastValue,numlastValue=numlastValue

Now, near the top of a code file you add these lines. So that the file is now.

value=42lastValue=nullchangeValue=(newValue)->lastValue=valuevalue=newValue# many pages of code hereinnocent=(nums)->lastValue=1fornuminnumsdoSomethinglastValue,numlastValue=numlastValue

Did you catch the error? Originally,lastValue was local to theinnocent function, but now it is global to the file and theinnocent function actually modifies it. We now have a bug waiting to happen when someone callsinnocent then checks the value oflastValue. Keep in mind there could be multiple screens of code between these two code segments.

Not Far Enough

Certainly, a language that is “just JavaScript” won’t be able to fix everything. Yet, despite radically altering the syntax of JavaScript and claiming to only expose the good parts of JavaScript, in some ways CoffeeScript doesn’t go far enough in fixing the issues of JavaScript. For example, the+ operator is still both numeric addition and string concatenation. That is frequently listed as one of the bad parts of JavaScript. Why no provide separate operators for the two? Likewise, thetypeof operator “is probably the biggest design flaw of JavaScript, as it is almost completely broken” according to theJavaScript Garden, but CoffeeScript brings its behaviour over unchanged. Instead CoffeeScript could have altered the meaning oftypeof to something that was more useful, for example thetypeOf() functionrecommend by Douglas Crockford.

Classes Are an Illusion

Many developers wish that JavaScript had classes. This has led to numerous alternative ways to emulate class like functionality in JavaScript and libraries that embody those various approaches. Many of the different approaches don’t interact well with each other. There is even debate on whether to use constructors requiring thenew keyword or to make everything a factory function.CoffeeScript has aclass keyword that makes it easy to create classes. However, since “it’s just JavaScript” they are just one particular emulation of classes on top of JavaScript. Consequently, they may not play well with your library of choice. More troublesome is that they make other language features more confusing. In particular thethis keyword. When creating a class you can’t help but feel thatthis should refer to the class everywhere within the body of the class. That is what it would mean for something to be aclass. But the actual semantics ofthis are unchanged. For example, if you declare a class with methods usingthis.

classCarconstructor:(@model)->drive:()->alert"You are driving a "+this.model;delayed:()->->this.model

BecauseCar is a class, one expectsthis to always refer to the current car object, but instead it behaves like regular JavaScript.

myRide=newCar("BMW")letsDrive=myRide.driveletsDrive()# alerts "You are driving a undefined"getModel=myRide.delayed()alert("Delayed model: "+getModel())# alerts "Delayed model: undefined"

Ultimately, JavaScript isn’t a class based language and classes never quite work right in it. I believe it is a mistake to push the language in that direction. For a more in-depth discussion of why this is the case, seeJavaScript Doesn’t Need Class by Ian Elliot.

I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. Thesuper idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.