3 ms·

First, good news: The Atom teams is (slowly) moving away from Coffeescript towards modern JS, and I think they'd agree (unofficially) that the choice proved to

by Lazare 11y ago

First, good news: The Atom teams is (slowly) moving away from Coffeescript towards modern JS, and I think they'd agree (unofficially) that the choice proved to be a mistake. Beyond that... 1. The JS world moves stupidly fast, and Coffeescript is a relic of a now-vanished age. It was born, it evolved, and it died. Back in those long ago days of, um, 5 year years ago, there was no ES6, and Coffeescript looked a lot more attractive. So much so, in fact, that ES6 stole a bunch of Coffeescripts better features. 2. If you're familiar with Coffeescript, it's terse and expressive and very readable. If you're not, it looks like gibberish. But that's true of any language. The proper critique of Coffeescript should be "hey, not a lot of potential collaborators know it, so it'll see unreadable to them", not "hey, Coffeescript is generally unreadable". JS is pretty confusing and unreadable if you don't know it too. Mind you, Atom was released 2 years ago, when Coffeescript was already starting to look dated. And it was an open source project looking for contributors so...yeah. Bad, bad choice. :)

andrewingram 11y ago
In fairness, I built a fairly large app using CoffeeScript and it still took a lot of brainpower to read it compared to JS. All the typical complaints about ambiguous-looking syntax match my experiences exactly. I ended up with a general workflow of having my Coffeescript source and the generated JavaScript sitting side-by-side so I could check that the output was what I was expecting. I've only had the urge to do that with ES6 and Babel a couple of times.
- Lazare 11y ago
  I built a pretty large app using Coffeescript, and I was about to say that I disagreed, and never felt like I needed at the generated output, but... ...now that you say that, I did end up going to the Coffeescript REPL on their website to test a bit of syntax a fair number times. I feel like a got used to it pretty fast, but I agree, a big chunk of Coffeescript's learning curve is getting past it's ambiguity, and there were some features I expressly avoided just because they were too confusing. Eg, I could never remember the difference between 'in' and 'of' in CS, so I just used underscore's equivalents. And then there were the comprehensions, and the weird scoping rules, and...yeah. I'll be honest, switching from CS to a modern Babel/ES6+ configuration, I thought I'd really miss CS, but I really haven't. I maintain that if you know CS, good CS code is easy to understand, but good CS code takes way too much work to write. :)
  - xiaoma 11y ago
    Interesting. Comprehensions are probably the main thing I miss. I liked the automatic returns and the @ shorthand, but whenever I find myself using Python for whatever odd reason, having comprehensions again is like encountering a long lost friend.
- klibertp 11y ago
  I wrote a couple of (simple) apps in LiveScript, which is similar to CoffeeScript, but is still way ahead of ES6 in terms of features[1]. I had to look at the generated source only once: when I was debugging and ultimately fixing a bug in the compiler. That's expected: had my C compiler had a bug, I'd have to look at asm output, too. Normally, pre-source maps, I'd also look at generated JS when debugging in the browser, but this is no longer the case. Other than the mentioned compiler bug I didn't have to look at the generated JS even once in my 2-3 years of using LiveScript. I think a good question to ask would be why did you have to look at the generated source. What did that give you, and what could replace it? Is looking at the generated source the most efficient way to achieve your goals? [1] The "killer feature" of LiveScript, for me, is its support for functional programming on par with support for OO. It reminds me of Scala or F# in that regard.
morgante 11y ago
> If you're not, it looks like gibberish. But that's true of any language. That's not true though. I'm not familiar with C++, for example, but it doesn't look like gibberish when I look at it. Nor does Go, as another example, even though I've never written a line of it. CoffeeScript, on the other hand, still is hard for me to parse—even as someone who has written thousands of lines for it. There are very real differences in readability between languages.

by Lazare 11y ago

andrewingram 11y ago

In fairness, I built a fairly large app using CoffeeScript and it still took a lot of brainpower to read it compared to JS. All the typical complaints about ambiguous-looking syntax match my experiences exactly. I ended up with a general workflow of having my Coffeescript source and the generated JavaScript sitting side-by-side so I could check that the output was what I was expecting. I've only had the urge to do that with ES6 and Babel a couple of times.

Lazare 11y ago
I built a pretty large app using Coffeescript, and I was about to say that I disagreed, and never felt like I needed at the generated output, but... ...now that you say that, I did end up going to the Coffeescript REPL on their website to test a bit of syntax a fair number times. I feel like a got used to it pretty fast, but I agree, a big chunk of Coffeescript's learning curve is getting past it's ambiguity, and there were some features I expressly avoided just because they were too confusing. Eg, I could never remember the difference between 'in' and 'of' in CS, so I just used underscore's equivalents. And then there were the comprehensions, and the weird scoping rules, and...yeah. I'll be honest, switching from CS to a modern Babel/ES6+ configuration, I thought I'd really miss CS, but I really haven't. I maintain that if you know CS, good CS code is easy to understand, but good CS code takes way too much work to write. :)
- xiaoma 11y ago
  Interesting. Comprehensions are probably the main thing I miss. I liked the automatic returns and the @ shorthand, but whenever I find myself using Python for whatever odd reason, having comprehensions again is like encountering a long lost friend.
klibertp 11y ago
I wrote a couple of (simple) apps in LiveScript, which is similar to CoffeeScript, but is still way ahead of ES6 in terms of features[1]. I had to look at the generated source only once: when I was debugging and ultimately fixing a bug in the compiler. That's expected: had my C compiler had a bug, I'd have to look at asm output, too. Normally, pre-source maps, I'd also look at generated JS when debugging in the browser, but this is no longer the case. Other than the mentioned compiler bug I didn't have to look at the generated JS even once in my 2-3 years of using LiveScript. I think a good question to ask would be why did you have to look at the generated source. What did that give you, and what could replace it? Is looking at the generated source the most efficient way to achieve your goals? [1] The "killer feature" of LiveScript, for me, is its support for functional programming on par with support for OO. It reminds me of Scala or F# in that regard.

morgante 11y ago

> If you're not, it looks like gibberish. But that's true of any language. That's not true though. I'm not familiar with C++, for example, but it doesn't look like gibberish when I look at it. Nor does Go, as another example, even though I've never written a line of it. CoffeeScript, on the other hand, still is hard for me to parse—even as someone who has written thousands of lines for it. There are very real differences in readability between languages.