I was a big supporter of their choice of CoffeeScript... until @jashkenas et al decided not to adapt to ES6. Now the language is dead and users are better off migrating to Babel and just dealing with the curly braces and commas.

I agree it's a pity.

EDIT: the blog post mentions support for Babel! http://blog.atom.io/2015/02/04/built-in-6to5.html

When did @jashkenas decide not to adapt to ES6? I searched and found this, which indicates they're open to it. Someone just needs to implement it.

https://github.com/jashkenas/coffeescript/issues/3162#issuec...

> "I think that such a pull request has a moderately slim chance of being accepted — it's probably still better to wait until real JS modules are finished and fully described. But it's worth a shot."

It's not that they've decided they're opposed to ES6, it's just that there's been no leadership in moving towards it. Which at this stage has left the language almost dead in the water.

That's really only a problem if you're contributing to the core, right? You can write your own packages in JS, and if you're just a user of the editor I don't see how that matters.

Sure, you can write your own packages in vanilla JS. Unfortunately though all of the documentation (and most packages themselves) are all written in coffeescript. Basically, the only way you can write a plugin in Javascript is if you already know Coffeescript (at least enough to read it).

It's just one extra barrier of entry for non-coffeescript developers. I personally thought about writing a simple plugin, went to the documentation and realized it was all in coffeescript with no JS option, and gave up. I simply don't have the mental capacity to learn another language that probably won't be around in 10 years.

I wouldn't even classify CoffeeScript as another language. It's really just javascript with some syntactical sugar. It took me about 20 mins to get comfortable with it.

It's another barrier to entry. Documentation is probably the worst place to encounter a new language, since the reader is already confused and frustrated.

CoffeeScript is a nice language, but I think it's reputation suffers from it's association with Ruby. Far too many CoffeeScript tutorials are aimed at Rails devs who don't want to learn new syntax.

It's a lot of syntactic sugar and things removed. Even the ?: operator which I use a lot. Typing "a = if b then c else d" is a huge wasted opportunity to just keep the ?: op. Plus there's no way to get the == operator even if you know you want it and understand the nuances.

I honestly find I use the ? operator in coffeescript far, far more often than I want to use a ternary conditional.

Fair enough on the == operator, but it's another that I have honestly never needed or wanted.

If c is truthy: a = b && c || d

Sure, but it's not the same, on one side I'd like to read the core and hack it on my own terms, on the other I'd feel more comfortable writing packages if I could just read the core and see how things work under the hood. I'd like it to be a "hackable editor" as it touts itself, but as it stands right now it's a "hackable editor if you are comfortable with CoffeeScript".

It will take you less than a day to learn to read CoffeeScript if you are familiar with JS.

Coffeescript is a very polarizing language. Most people appear to either love it or hate it vigorously.

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

CoffeeScript was released in a time when ES6 wasn't yet a thing as far as most developers were concerned. It was also a time when JS saw a huge influx of new developers coming from other languages. CoffeeScript itself draws heavily from Ruby (and some Python), which explains why it was rapidly adopted by the Ruby community and became part of Rails (just like Sass replaced CSS).

When I first revisited JavaScript after a long time writing Python code, I was quite fond of CoffeeScript because it let you pretend you're not actually writing JavaScript and because it enabled a lot of idioms that didn't exist in vanilla JavaScript.

CoffeeScript is decidedly not an extension of JavaScript. It doesn't build on existing JavaScript idioms and just add syntactic sugar (partially because many idioms of modern JS simply didn't exist at the time and there was less consensus about them) -- it substitutes idioms from Ruby and Python and implements their syntax, all the way down to changing how variables are declared and how the equality operator behaves.

CoffeeScript is written for programmers who understand JavaScript but don't want to write JavaScript when creating JavaScript code.

Thanks to Babel.js ES6 (now ES2015) is now a thing. Most of the new things CoffeeScript brought to the table for JavaScript programmers are now satisfied by the language itself or syntactic extensions supported by Babel. There is a well-understood and well-defined class syntax, there are arrow functions and tons of syntactic shorthands like method literals and object/array destructuring. What's more, because these are now officially part of the language, Babel itself just serves as a stopgap while we wait for the JS environments to catch up.

Outside its original use case of allowing Ruby programmers to avoid writing JavaScript, CoffeeScript is obsolete and (at least in terms of hype and momentum) dead. It has outserved its usefulness and has given way to more specialised languages (e.g. ClojureScript) and Babel.

It's unsurprising that Atom core is written in CoffeeScript if you consider that GitHub is and always was predominantly not a JavaScript company but a Ruby company. It is heavily invested in the Ruby world and CoffeeScript is part of the Ruby world more than it is part of the JavaScript world.

I'm not sure whether CoffeeScript's role in the Ruby world will change anytime soon, but outside that microcosm, it has become irrelevant and is quickly fading into obscurity. It served a useful purpose at the time and it has certainly influenced the development of ES6 but other than allowing Ruby programmers to avoid writing JavaScript it's just no longer worth bothering with.

Also note that at the time everybody was trying to replace JavaScript with new languages (which were either supersets of JavaScript (like TypeScript), shared a common subset with JavaScript (like CoffeeScript) or did something else entirely (like ClojureScript)).

Babel is part of a general movement towards unification. Babel out of the box has support for JSX and type annotations (which are already just defined in terms of extensions to JS). Google's AtScript has been redefined as an extension to TypeScript (which in turn seems to be moving towards redefining itself as an extension to JS). I think this is a far more productive development than everybody trying to create their own compiled-to-JS language from scratch.

In a nutshell: I don't hate CoffeeScript, but I consider it a major smell when evaluating libraries and projects. If it's written in CoffeeScript it might as well not be written in JavaScript at all.

Yeah CoffeeScript is pretty easy to learn and doing things like configuring snippets seems like a good use for it.

In general tho, I am pretty hesitant to go all in with CoffeeScript, mainly because you still have to watch and massage the javascript output, negating any time saved for me at least.

You can write in Plain JS if you want (it supports Babel, apparently); CoffeeScript is not a hard limitation, just a preference.

The UI library is in coffee script; if you want use a UI for your plugin, youre pretty much stuck using it.

(..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)

You can call CoffeeScript functions from JavaScript and vice versa. There's no reason that you can't use the UI library from code written in JS. The fact that its written in CoffeeScript is an implementation detail

Inheritance. DOM element functions. Gee, I must have never tried this and have no idea what I'm talking about right?

I tell you what, you try it and tell me how it goes for you?

It's really not that simple.

But all the docs are in Coffeescript, and it's quite hostile to a new dev.

Grab a cup of coffee, start reading the CoffeeScript documentation. Your coffee won't even by cold by the time you finish with it. Start coding.

Seriously, CofeeScript is tiny.

We've been working on Atom for a long time. I think that CS was a great choice when it was made some years ago, and I can say that the core team quite likes ES6 (which directly addresses a lot of the same JS warts that CS was designed to avoid). That said even if we decided to move to ES6 today, it's a big ship and it takes a long time to turn :)

Do you really care that much which dialect of JavaScript your text editor is written in?

It's a bit like worrying about the brand of gruel you're eating.

CoffeeScript is actually pretty cool, from a few minutes spent with it it was just syntaxic sugar for js. Why don't you like it?

Did you miss that you can't create local variables?

WHAT? You mean, you can't declare them without initialization. Oh well, you can't; it's also impossible in Python or Lua. Why is it a bad thing?

Let's not confuse matters here: in both those languages an initialization-assignment will introduce a new binding within function scopes. In CoffeeScript it will always be the parent scope's binding, which means that you must take extra care not to introduce variables used in scopes above, or below, at any given time.

On the other hand, confusing both concepts is bad because it makes it harder to reason about scope, and it has been the cause of much confusion regarding closures in Python and Ruby.

Lua has perfectly sane lexical scope for its local variables. Don't mix it with Python and Coffeescript.

Ah, true, I checked again and you're right. Too late to edit.

you can if you cheat: http://coffeescript.org/#try:%0Aa%20%3D%201%0Ax%20%3D%20-%3E...

(I jumped ship to babel though)

Nothing stops you using javascript in your own packages

And by "nothing" you mean the entire UI library

I quote:

> The UI library is in coffee script; if you want use a UI for your plugin, youre pretty much stuck using it.

> (..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)

That's something I like about it.