[okfn-dev] Pro/cons of coffeescript versus javascript

[Rufus Pollock]

Useful thread and comments from Nick Stenning re. javascript and
coffeescript (specifically re annotator project ...) that I thought
may be of interest to the list.

Rufus

---------- Forwarded message ----------
From: Nick Stenning
Date: 22 January 2011 14:49
Subject: Re: Annotator v1.0.0beta2

[...]

On Thu, Jan 6, 2011 at 13:13, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> Hi Nick,
>
> Thanks for your work so far and I look forward to seeing the summary
> email to okfn-help.

Now back on my todo list.

> Already in talking with a couple of potential developers their
> immediate response is "what is coffee-script" and why can't i use pure
> javascript :) Also I note one more knowledgeable developer (who had
> used coffeescript) mentioned concerns about debugging and said
> ultimately he'd found it did not bring a lot of benefits over
> javascript (though of course he is not the ultimate authority!)

I'm not sure the criticism/queries of those who haven't used it is
particularly useful. "I know Javascript, why can't I use that?" is a
pretty normal response to something new and unknown, but that doesn't
mean it's a useful one. For starters, it's not a new language to
learn, it's a modified syntax. When I switch languages, I don't have
issues adapting to syntax, I have issues adapting to language
differences. This simply doesn't arise when writing CS.

As someone who's been coding Javascript for longer than I care to add
up, I find that CoffeeScript is essentially the long-sought-for
"Javascript: The Good Parts", for various reasons. Here are a few:

1) No-one likes missing semicolons in C, and Javascript is even worse
on this issue (not just semicolons: the more general problem of
syntactic fragility) because the behaviour of different browsers isn't
well defined. IE will throw a hissy fit if you have one too many
commas in an object declaration, whereas almost everything else will
swallow it just fine.

2) Javascript's power, especially on the web, comes from its use of
functions as first-class objects. It's sad, then, that it has a
relatively verbose syntax for declaring and calling (not to mention
rebinding) them.

3) Javascript's prototypal inheritance model is well-intentioned, but
for some things we find it easier to deal with by bending it into a
more classical-looking form.

CoffeeScript addresses each of these issues, and many others.

1) CoffeeScript is syntax normalizing, and more importantly, syntax
light. It discards semicolons, braces and commas in favour of a more
pythonesque indentation based syntax. I like this, and so should you!

2) CoffeeScript's '->' is a short and elegant syntax for function
declaration. '=>' is an even more powerful piece of syntax which one
uses all over the place for function rebinding, and almost completely
avoids the need for the ugly "var self = this;" pattern you see
throughout any more complex Javascript.

3) CoffeeScript has in-built support for a "class" declaration syntax
which behaves in a totally unsurprising and very useful way.

And here are just a few other extremely useful features of CS when
writing real programs:

- Default parameters: "myfun = (a=1, b=2) -> a + b"
- Parameter splats: "args..." functions as "*args" in Python.
- Existence checking: "variable?" is a lot less verbose than "(typeof
variable !== 'undefined') && ..."
- List comprehension! This is a *huge* one, as a Python coder can
surely appreciate.
- Heredocs. Extremely useful in templating.

In short, I think this issue is probably best summarised by the CS
website itself: "The golden rule of CoffeeScript is: 'It's just
JavaScript'".

It's a hugely productivity-enhancing syntax modification of an
existing language. For me, that's the be-all and end-all. There are
disadvantages: the slightly woolly "concerns about debugging" you
mention above is presumably the same issue as in any
compiled/preprocessed language -- line numbers in generated Javascript
won't be the same as those in the source file. This is true, and a
valid concern. My opinion is that the debugging advantage gained in
writing clear, maintainable code (hard to do with JS, hard not to do
with CS) more than outweigh such issues. What's more, there's been
extensive discussion about this issue in the CS community:

https://github.com/jashkenas/coffee-script/issues#issue/558

> I was wondering how I could upgrade my storecouchdb plugin
> [...]
> Can I just copy and paste the 'top' sections and hope

If plugin development is about copy-paste-and-hope, then I'm a little
bit worried. There's an extremely simple API for writing a plugin.
It's documented in the README. I'm not sure what more there is to it.
If you want to write a plugin in Javascript that inherits from a
plugin originally written in CS, you can do that. If you want to write
a pure-Javascript plugin, the README tells you how to do that.

It's not Annotator's role to teach people Javascript -- which is kind
what it sounds like you're saying.

[...]

> To summarize:
>
> 1. While I am not completely against coffee-script it would be good
> idea to understand something of its exact advantages

I hope I've given you some understanding now.

> 2. We need to go on supporting javascript plugins so some
> documentation/instructions on how to write a plugin *in javascript*
> would be needed.

I'm puzzled as to why you kept banging on about this in this email
when if you'd read the README you would have seen that such
documentation does exist. =)