> It's also a kick in the gut to efforts to fix the shortcomings of ECMAScript like ES6 [1].

irony alert: Brendan Eich has said publicly that CoffeeScript was the impetus for several of the features that made it into ES-6, like fat arrows.

Without CoffeeScript, lots of people wouldn’t have known that they wanted some of the things that are in ES-6.

As it is, you don’t need CoffeeScript to develop for Atom. Which is part of the beauty of CoffeeScript. It’s interoperable with what you’re doing today.

  irony alert: Brendan Eich has said publicly that CoffeeScript was the impetus for several of the features that made it into ES-6, like fat arrows.

ES6 is a real specification supported by JavaScript engines.

  As it is, you don’t need CoffeeScript to develop for Atom. Which is part of the beauty of CoffeeScript. It’s interoperable with what you’re doing today.

The core of the Open Source project is in CoffeeScript.

Let's say the community had their way, and Atom was rewritten in JS well.

There's still a JS/V8/Chrome for a dependency. On an application where we're rendering huge walls of text - we forgo native redraw. Crucial to response time.

It's fun and time-saving for core developers to forgo the grueling work of portable, native, fast code.

But who pays the cost for the shortcuts?

> The thing that turned me away from Atom and its' development is CoffeeScript.

...

> There's still a JS/V8/Chrome for a dependency. On an application where we're rendering huge walls of text - we forgo native redraw. Crucial to response time. > What makes Atom a viable choice when there already is free, open source, native, cross-platform editors with great plugin ecosystems?

I guess maybe CoffeeScript isn't what turned you away?

As a node developer, seeing any official, open source package in CoffeeScript is a red flag.

The sibling I made a link to a thread about CS in Atom. The creator of express.js has his take:

"Hell I had to rewrite a coffeescript driver this week because I can't have our company relying on things written by people who are unfamiliar with javascript, throwing strings, super awkward apis, lots of indirection, and stepping through the compiled source is a nightmare. It's not like I didn't want to contribute, I even tried for a while, but it's just not worth the hell, it was quicker to just rewrite the thing. Not to say all coffeescript libraries are written poorly, but regardless you're really not gaining much, just losing a lot." [1]

If you write an open source application in CoffeeScript, you're not doing the community a favor, you're doing yourself a favor. They pay the penalty.

[1] https://discuss.atom.io/t/why-coffeescript/131/8

FWIW, that same creator created Jade and Stylus which are pythonic like CoffeeScript. What's wrong with HTML and CSS? I could never take his stance against CoffeeScript seriously.

I can't speak for him. I've had fellow programmers love CoffeeScript for their own personal / client projects - but they conceded that for the real deal - a public open source project should stay in JS. Otherwise, it'd scare off swaths of top tier JS coders from contributing. Atom serves as an example of this practice [1].

The smell CoffeeScript in core gives off to them - while I don't subscribe to this - is that "it's an amateur job, don't bother". You don't write open, core code in an abstracted language. That's so suspect. Personal / internal projects are OK, a few I save CS specifically for those situations.

If you look at the source of Express.js, you can see the javascript has it's own aesthetics to it. You can think of express/connect as serving exemplary of node.js code, for now.

On a topic of the CoffeeScript creator, Jeremy Ashkenas also created Backbone and Underscore. These are pretty much examples of top tier JS in the browser. The projects are known for their annotated source:

- http://underscorejs.org/docs/underscore.html

- http://documentcloud.github.com/backbone/docs/backbone.html

You can't output this kind of code with CoffeeScript. You have to let in sink in and understand the patterns (the way .extend works in underscore and how Backbone builds upon the idea to add it to objects.)

[1] https://discuss.atom.io/t/goodbye-atom-some-feedback/12301/3...

Your comment fills me with equal parts irritation and curiosity, just because it's so far from my experience. I use CoffeeScript every day, and I experience not even the mildest of tooling or debugging hiccups. And I find CoffeeScript hits such a sweet spot — some of the best bits of Ruby and Python syntax, with the first class functions and raw speed of JavaScript. Mozilla's source maps implementation is pure JS, so you can take that anywhere (e.g. I use it with JavaScriptCore on iOS). Can you elaborate on these nightmares?

I second this; though, to be fair, source maps in AtomShell have been flaky at times when selecting breakpoints with CoffeeScript. I have turned my source mapping off and debug the unminified resultant JavaScript.

You actually don't have to touch coffeescript to develop for Atom or Electron.

EDIT: here's a demo app with zero CoffeeScript: https://github.com/thom-nic/electron-demo

I agree, have an up vote. I wish this community was nice to each other, instead of telling you why your personal choice is wrong and and trying to prove that they are right. It's not about being right or wrong, because there is no right or wrong. Just tools to do the job.

Ignore the haters, they will always exist. Just keep build great stuff.

Your comment reads better as disagreeing with the comment you responded to.

> The thing that turned me away > As someone who loves

He is only stating his feelings. He's not trying to put anyone down or argue that his way is better. Unlike a lot of the comments.

That's like saying you won't use Rails because it's written in Ruby and not C.

Also, it's nice to work in a language that has the right features and not just all the features. I like CoffeeScript as much for what it doesn't have as for what it does have. I recently saw this piece of code:

    new Array(26)
      .map(function (item, index) {
        return String.fromCharCode(65 + index);
    })

as a "heads up" for map lovers. That's the kind of code that people write when they're tacking the latest new feature onto someplace that it doesn't belong. This code isn't just semantically wrong, it's stylistically wrong. Having a less schizophrenic language helps jr guys avoid code like the above.

    const caps = new Array(26).map((item, index) => String.fromCharCode(65 + index));

It's not wrong. Could maybe be better though.

Longer, harder to reason against...

    const caps = new Array(26).map((item, index) => String.fromCharCode(65 + index));

Shorter, easier to reason against.

    const caps = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'.split('');

LGTM

It is wrong. "new Array(26)" creates an Array with preallocated space for 26 elements (instead of 26 'undefined' elements, as one might expect), and calling .map() on it will return another empty array. The semantics here are particularly difficult to reason about because map is specified to not execute its callback on undefined elements.

Someone will probably chime in here with a correction, but the point is this -- JS is NOT a friendly language to deal with.

It will iterate just fine, there are no values (undefined) for each `0` through `length-1`

    new Array(26).length === 26; //true

Seems like it doesn't, I recently read about this gotcha so I tested it out in JSBin. Using lodash map works as expected, though.

JSBin: http://jsbin.com/vasulumeti/1/edit?js,console

StackOverflow: http://stackoverflow.com/a/5501711/211291

As others have pointed out, the semantics are pretty hard to deal with. But, it's the style that I think is the really bad part of this snippet. Why would you create an array of empty elements to iterate over just to grab the index? In CoffeeScript, however, the language guides you to this solution:

    [65..90].map (number) -> String.fromCharCode(number)

where you're operating on the elements of your array and you don't care about their index.

> Why would you create an array of empty elements to iterate over just to grab the index?

Because it's the shortest way to do it in that language.

I think something like:

    [A-Z].reverse

or:

    reverse([A-Z])

might even be better. Do you know of a language with that syntax?

If you want an index, use an index:

    for (1 = 65; i <= 90; i++){...}

It's not like the syntax is that bad. But, iterators are simpler than indexing a collection. Iterators work with data structures like linked lists where you don't really have an index. And, they work when the collection changes while you're iterating it.

But you can't also output an array without additional lines of code.

You still haven't realized that _your_ solution won't output anything without additional lines of code, have you?

I have, except that it's not really my solution. I was just cleaning up the example to make it more readable, as that seemed to be one of the complaints of the OP.

Idiomatic JavaScript is terrible to read. I'm not one for metalanguages but I'd be hard pressed to argue against it in this case.

That 'idiomatic' JS is but a mere illusion perpetuated by a VM written in C++. We can do this all day.

I'm developing an app using Atom/Electron and I'm pretty sure you don't need to use CoffeeScript at all. It's Node.js and a browser.

To all the sibling commenters defending the merits of CoffeeScript:

- https://discuss.atom.io/t/why-coffeescript/131

- https://meta.discourse.org/t/is-it-better-for-discourse-to-u...

Translation: "more people know JavaScript than CoffeeScript, so you shouldn't bother with CoffeeScript"

More people are familiar with Notepad than vi. Does that make vi a bad choice?

> More people are familiar with Notepad than vi. Does that make vi a bad choice?

That analogy doesn't work, because editors don't have network effects, whereas programming languages do.

> editors don't have network effects

The 82 plugins in my current vim setup really, really beg to differ.

There's many reasons why that analogy doesn't work, and "network effect" isn't one.

Appropriate tool, appropriate job.