
Discourse ditches CoffeeScript - fernandezpablo
http://meta.discourse.org/t/is-it-better-for-discourse-to-use-javascript-or-coffeescript/3153
======
ansman
If you understand programming (there is a difference between knowing how to
program and understanding, a lot of people lack the latter) there is
absolutely no difficulty learning CS if you know JS.

I've been coding CS for over a year now and I like it, I've never found it
hard to debug and it's just easier to read.

~~~
eurleif
CoffeeScript's scoping is broken.
[http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-
coffe...](http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-
coffeescript/)

~~~
snprbob86
I greatly prefer Scheme-like lexical scoping. However, JavaScript does not
implement lexical scoping properly. Given the particularities of JavaScript's
inadequacies, I think that the CoffeeScript design is very reasonable. It's
certainly not "broken".

Lots more discussion here: <https://news.ycombinator.com/item?id=3379962>

~~~
batgaijin
Um... I believe JS does have proper lexical scoping. Could you source any
evidence to the contrary?

~~~
snprbob86
JavaScript's lexical scoping is function-level. There is no block level
lexical scoping, so variables are "hoisted" to the containing scope. This is
why people use the (function(foo){...})(bar) trick to create lexical scopes,
such as when looping (CoffeeScript's `do` keyword embodies this pattern). In
my opinion, "proper" lexical scope implies shadowing without hoisting.

~~~
dclowd9901
If you understand hoisting as a characteristic of JavaScript, its behavior is
very predictable, and thus, hardly broken -- merely tricky if you've yet to
encounter a hoisting-related issue.

That said, I find almost any issue with writing JavaScript can be easily
mitigated by utilizing JSHint, and you get the added benefit of sticking with
the base language, which is better because if you're writing raw JS everyday,
your skills are more transferable than if you're writing CS every day if only
for the fact that you can still write JS in a CS-only stack, but you can't
write CS in a JS-only stack.

------
ricardobeat
Did they? I can't get to the end of the thread 'cause their infinite scroll
thing is not working on mobile safari. Looks like they should focus on coding
instead.

~~~
sams99
our mobile story sucks at the moment, we are dying for a mobile friendly skin
at the bare minimum, contributions totally welcome.

you can get it to work on mobile safari in portrait if you zoom in / out ...
but that just too hacky

~~~
watmough
Your web-site also sat with the spinner running for 4+ seconds.

You might want to try providing it in HTML format.

------
raganwald
I find this a curious debate to have so early in Discourse's life. There
doesn't appear to be a pain point, so it's mostly speculation. If this
happens, then that consequence, but if this happens, then that other
consequence...

I would stick with CoffeeScript until it becomes painful. There is relatively
little downside risk. If and when you have great people refusing to contribute
code because they hate CoffeeScript, well, that'll be a pain point. On the
other hand, what if you get a bunch of other people who like contributing code
because they can do it in CoffeeScript?

Are there meaningful statistics collected? Until there are, or at least a
weighty collection of anecdotes, I'm sure there's something more important to
worry about.

~~~
calibraxis
Disclaimer: I don't know Discourse's situation in detail, and I use
CoffeeScript on node.js, not the client.

The sheer mass of anti-CoffeeScript FUD ironically makes it more likely that
they'll get more contributions if they go back to JavaScript. ;) YOU might
know people who seriously consider Erlang and Clojure, but most people respond
badly to superficial syntactical differences.

Of course, is "contributions" really the best metric? What about productivity
or quality? And can they make it so that people can easily contribute
JavaScript?

(Even among people I know, I've heard such irrational FUD against
CoffeeScript. And I know it's FUD because none of their boogiemen came true
after I aggressively introduced it into their codebase. They now use it every
day without concern. Most people hate innovation, including programmers.)

In particular, the ES6 argument sounds like FUD. Did they link to timelines
and CoffeeScript developers' opinions? And where's the tradeoff analysis
comparing the immediate productivity benefits of CoffeeScript vs some future
ES6 event?

------
jtchang
Am I the only one that has trouble parsing this CoffeeScript? I thought the
syntax was suppose to be cleaner than plain javascript:

MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' +
@get('lastName') ).property('firstName', 'lastName')

How the hell am I suppose to read that?

~~~
nahname
If you were to read the equivalent javascript as a one liner it would be hard
to read too. Probably more so. Really, all you are pointing out is that you
can write shitty code in any language. No language protects you.

If you write beautiful javascript, you will write beautiful coffeescript and
it will be 20-60% smaller. Reading less lines is less reading, this helps me.

~~~
TazeTSchnitzel
Nonsense. The equivalent JavaScript is clearer, albeit more verbose.

~~~
nahname
Neither is very palatable.

MyApp.president = Ember.Object.create(({fullName: (function() {return
this.get('firstName')+' '+this.get('lastName');}).property('firstName',
'lastName')}));

MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' +
@get('lastName') ).property('firstName', 'lastName')

~~~
TazeTSchnitzel
At least I can look at the first one and it's more obvious to me what it does.
The braces help.

------
adamesque
If I've understood correctly, the most compelling argument (or at least the
most seemingly objective one) is that CoffeeScript conflicts with planned
features of ES6+, meaning that there is a risk that large CoffeeScript
projects will be locked into the ES5 feature set.

Since Discourse is planning on being around long after ES6 becomes widely
available, it was a winning argument.

[http://meta.discourse.org/t/is-it-better-for-discourse-to-
us...](http://meta.discourse.org/t/is-it-better-for-discourse-to-use-
javascript-or-coffeescript/3153/19)

Also, one of the big reasons the Discourse devs liked CoffeeScript is because
it makes it hard to commit common JS errors. Building JSHint into their
workflow can help bring this protection back.

~~~
jacquesc
Seems like a very narrow mindset. Why would they assume coffeescript won't
adapt to ES6? CoffeeScript compiler can change quickly while maintaining
backwards compatibility. ES6 standards move at a snails pace.

There's other perfectly valid reasons to use pure-JS on a large open source
project, but the ES6 thing is a red herring IMHO.

~~~
cwp
What makes you think CoffeeScript can target ES6 while maintaining backwards
compatibility? Did you read the discussion? Wycats makes a very good argument
for the opposite position.

~~~
jacquesc
Yep, I did read the discussion. I think wycats brings up a perfectly good
concern, but the key point which he misses is that there is time, and
CoffeeScript can change to fix what I think is a very solvable issue.

The current estimate for ES6 support in browsers is 2014. CoffeeScript only
hit 1.0 about 2 years ago, and has had 3 minor point releases since then.

For me it's not hard to imagine a CoffeeScript 2.0 release at some point next
year that targets ES6. It could make a few syntax changes, and ship with some
helper tools (or a 3rd would create it) to detect possibilities in your
previous code and tell you where you need to tweak to make it compatible.

~~~
cwp
So, basically, CoffeeScript _can't_ target ES6 while maintaining backwards
compatibility, but it doesn't matter, because they have time to manage the
transition. Ok, that may well be.

Personally, I agree that ES6 isn't that big an issue, but for a different
reason: when they decide they want to take advantage of ES6, they can always
make the switch to Javascript _then_ ; there's no reason it has to happen now.

~~~
rodw
_CoffeeScript can't target ES6 while maintaining backwards compatibility_

Is that really true? I mean, it is not as if JavaScript is a _subset_ of
CoffeeScript. [1]

It seems to me that the worst case scenario here (for CoffeeScript) isn't
backward incompatibility, it is drifting further away from the JavaScript
syntax/grammar than one might like. Take the `for/of` concern raised in the
thread. Why would CoffeeScript _need_ to change its semantics to match that of
ES6? ES6 could introduce a new and different meaning of `for` and `of`
(whatever that is) but CoffeeScript could keep its meaning for `for` and `of`
(whatever that is). The problem, if any, will be in "wetware".

Isn't the analogy here something like

 _CoffeeScript is to JavaScript as Closure is to the JVM_.

Does Closure break if the JVM adds new features? Why would we expect
CoffeeScript to?

[1] Excepting the back-tick delimited escaping for literal JavaScript, but
that's not an issue here.

~~~
cwp
Because of the 1JS principle, ES6 will be a strict superset of ES5.
CoffeeScript can maintain its existing semantics, produce the same JS output
that it does now, and nothing will break. But then it's not really targeting
ES6, is it? It's targeting ES5 and benefitting, as all Javascript code does,
from ES6's backward compatibility with ES5.

So sure, if we're not interested in the new features of ES6 in the first
place, then I grant that ES6 compatibility is a red herring.

~~~
rodw
To be candid I don't know the details of what is changed in ES6. Is there a
specific aspect of ES6 you're thinking of?

But the new features of ES6 aren't features of CoffeeScript. Why would we
expect them to be?

It's like noting that Java 7 adds support for strings to switch statements and
wondering how the syntax of Closure is going to change in response.

There is no strict requirement for the languages to be tied together at a
syntax level, they just "compile" to something compatible.

There may be strong technical reasons for the CoffeeScript _compiler_ to take
advantage of the new features of ES6, but that doesn't force a change to
CoffeeScript-the-language. (In other words, it _can_ target ES6 while
remaining backward compatible.)

I wouldn't be surprised to discover I'm missing something, but I'm genuinely
confused why this is seen as a technical problem. It's not that CoffeeScript-
the-language is "not interested in the new features of ES6", but that,
technically speaking, CoffeeScript-the-language is not interested in ES-the-
language at all.

Apples and oranges. (Or maybe lemons and limes.)

As an aside, I _do_ see this as a potential social problem. CoffeeScript would
probably like to remain conceptually-compatible with JavaScript, and that gets
much harder if the two have different semantics for similar syntax-es, but I'm
going to guess this isn't the only example of it.

------
zalew
> CoffeeScript has significant whitespace. So instant no. It makes it a pain
> in the butt to parse. It's annoying. Most people (except for Python
> developers) don't like it. Due to being difficult to parse, you will have
> problems when you try to refactor. Not to mention the problems of re-
> indenting everything when you have really long and ugly blocks you want to
> clean up (happens).

maybe people should stop writing unindented ugly blocks in their non-indent-
significant language then?

~~~
Danieru
No one is writing un-indented code. The issue is lack of metadata for
automatic indentation.

In C if I shift a block of code a quick gg=G will reformat and reindent.
Possible because blocks are explicit and whitespace is separate from scope. By
the same token autogeneration of {}'s is impossible in C. This is obvious but
obfuscated in Python from whitespaces' overloading.

The issue is autogeneration of blocks. In any language blocks are a
fundamental aspect of programming. Blocks affect the function of a program.
Since we lack self-programming computers we also lack autogeneration of
blocks. Python's issue is that a non-fundamental aspect of programming has
been paired with a fundamental aspect of programming.

~~~
shirkey
>Python's issue is that a non-fundamental aspect of programming has been
paired with a fundamental aspect of programming.

Python's "issue" is that it considers readability as a fundamental aspect of
programming and that whitespace is critical to that end. Whether that suits a
particular programmer is a matter of personal preference.

------
fourstar
Is it just me or is anyone else finding it weird viewing a thread on Discourse
from HN? It's basically the same thing IMO (although obviously this is a
Discourse site announcement). I just hope this doesn't become a "thing" as
it's just essentially same as linking to a forum post.

~~~
ChuckMcM
I just thought it was a way for the Discourse guys to get people here to look
at a 'real' thread in Discourse to get a feel for the system. If it is
compelling enough to get someone to register and comment its a double benefit.

That said, the annoying ones for me are links to Google+ things, the URL says
"google.com" but the content is various.

~~~
Kerrick
That's one of the very few things HN should borrow from reddit: use subdomains
in the URLs, so we could see (for example) that it's from plus.google.com.

------
smnrchrds
History repeats itself. This topic reminds me of QWERTY vs. Dvorak. People
continue using something because everyone else is and they always have; not
because it's the optimal option.

~~~
dsego
There's no proof Dvorak is any better.
<http://www.reason.com/news/show/29944.html>

~~~
subsection1h
Wrong.

"First, Dvorak is very good at keeping fingers on home row - 71% of keystrokes
land there (compare this with 34% for QWERTY). This alone is worth the price
of admission. Dvorak bottom row usage is very low at 9% (15% for QWERTY).
Dvorak favours the right hand by 14% (QWERTY favours left by 15%). Dvorak has
more uniform finger usage and makes greater use of the pinky (18% vs QWERTY's
10%). The cumulative run statistics illustrate Dvorak's strength in
alternating hands. 62% of successive keystrokes on Dvorak do not use the same
hand (rh(0)) and 88% of adjacent keystrokes use the same hand at most once
(rh(1)). In contrast, with QWERTY only 51% of successive keystrokes do not use
the same hand and only 76% use the same hand at most once. QWERTY forces the
typist to use the same hand repeatedly, which limits the amount of rest and
increases effort. Dvorak's preference for the use of the right-hand give it
longer right hand runs with only 47% of keystrokes that use the right hand
being followed by use of the left hand (61% for QWERTY). The corresponding
statistic for the left hand is reversed, with Dvorak at 76% and QWERTY at
42%."[1]

The authors of the Reason Magazine article from 1996 that you linked to stated
that "Ergonomic studies also confirm that the advantages of Dvorak are either
small or nonexistent." But the authors cited only one nameless, undated study.
This promotion of QWERTY isn't surprising seeing as how Reason Magazine is
written by ideologues whose goals include the promotion of the idea that the
invisible hand of the market is never wrong.

You should consider getting your information from specialists who are active
researchers rather than the writings of non-specialists from previous decades.

[1] <http://mkweb.bcgsc.ca/carpalx/?dvorak>

~~~
dsego
You should take a look at the research behind Colemak (and a less known layout
named Workman), to see that Dvorak is a subpar layout, with misguided
reasoning and poor optimisations.

------
benaiah
I supported the switch to JavaScript, despite being an avid Coffeescript
developer. Why? Because any CoffeeScript developer worth their salt already
knows JavaScript, and can translate the JS to CS and back quite simply
(admittedly, it's not as nice as hand-written CS, and the compilation loses
comments, but I still prefer it to writing the JS by hand if I'm doing a
bunch). But many, many JS developers don't know CS, or don't like it.

Now, this only affects the first official client. I imagine that there will be
a CS port of the JS client as soon as the switch is made. That's the great
thing about using a client to a REST API - you can have several different
front-ends. If this was to be the only client, I'm not sure if I would support
using JS over CS.

(btw, I'm @benaiah on meta.discourse.org - I'm in the referenced thread)

------
kmf
I think the advantage of this project being open source becomes really clear
in situations like this: I'd imagine js2coffee[1] will cover most of their
bases, but in the situation that it _doesn't_ , they have a (pretty active)
Github community to fall back on for the finicky bits of conversion.

[1]: <http://js2coffee.org/>

~~~
jaredmcateer
It's been a while since I looked at js2coffee, it's nice that they've
eventually fixed the lack of transferring comments issue.

------
niggler
I would discuss how I feel about coffeescript and interstitial white space
sensitivity and the ilk, but I'll point to a blog post which expresses most of
my views neatly: [http://blog.izs.me/post/10213512387/javascript-is-not-web-
as...](http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly)

------
Herbert2
I've found that CoffeeScript is great at standardizing the various styles of
coding JavaScript that exist in an office.

------
itsbits
good..now i will look into Discourse...

------
camus
I developped a little layout library ( work in progress ) which is a port of a
flash lib. and frankly coffeescript made it really easy and made me wrote far
less code that pure javascript.

One can write readable code with Coffeescript , i use parenthesis in big
scripts because it is more readable , and i dont use classes where not
appropriate.

CS helped me write better javascript without the badparts so i dont need to be
a human compilator and fix javascript each time i write it. I should not have
to.

<http://mparaiso.github.com/Coordinates.js/>

It is not for everyone , but significant white spaces are not a problem if one
is used to indent his code properly. I tried typescript too , which is good,
but i found coffeescript more expressive. The truth is , i enjoy writing CS ,
i dont writing JS.

