Why coffeescript?


#1

Why not ES6? Desktop app using node.js/V8 is almost the perfect place to use (and let others use) ES6 right now.


Goodbye Atom, some feedback
Atom moving to JS?
Anybody planning to use babel / ecmascript 6 instead of coffee script
Topics that start with "Why"
JavaScript Syntax Highlighting Error
No more Coffee. Decaffeinate the Atom's Core. Atom without Coffeescript
Sigh. Docs are not clear. Working with ContextMenus
Goodbye Atom, some feedback
Goodbye Atom, some feedback
ES6 Package Generator and Guides
#2

Interestingly and completely unrelated to Atom, we had a very long discussion at Discourse about this issue:

We ended up going with JavaScript


#3

See the discussion over here about using plain old JS in Atom: Will there be thorough documentation for plain JavaScript developers?


#4

You can use plain JS to develop packages:


#5

It would be nice if all the open source components of atom where written in JavaScript.

The usage of CoffeeScript (opinion aside) increases the barrier to entry. There are more JavaScript developers. Usage of JavaScript would increase contribution to the project.

It appears both discourse & rethinkdb have seen the negatives of coffeescript wrt contributions and open source collaboration.


#6

Agreed. Collaboration in core would see much higher adoption if in plain JavaScript.


#7

I don’t agree that CoffeeScript raises the barrier to entry by enough to warrant converting core packages to JavaScript. CoffeeScript isn’t that different. It’s mostly syntax preference in my opinion.


#8

Agreed, the idioms used by coffeescript devs are often quite different than the “norm” in js-land as well, so that alone leads to some pretty awkward APIs when interfacing with “regular” javascript. I also agree with the ES6 comment, there’s very few things that coffeescript really gives you on top of what we’ll have as a standard soon, so this seems like a bullet to the foot really. There’s no questioning that it will have an impact on contributions, personally I won’t even look at it because I might as well stick with the obscure editor I already use.

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.

Just my opinion :slight_smile:


#9

I would have preferred plain JavaScript in Core, too. We can relatively safely say that JS will still exist, evolve and be standardized in 5 or more years where CoffeeScript is a lot more questionable. CS tends to clash with new ES.x features, too. The community for JS is just much bigger than for CS - and you wouldn’t really lose any functionality or benefits of CS.

Promoting other new web standards than ES6 could also be beneficial. Atom already use flexbox, because it gives us functionality which didn’t exist before. Why not using Web Components? It gives us the feature to scope stylesheets. This is something really important, if you want to safely extend the GUI.

I do understand the benefits for using CSON. JSON is very limited - mainly because it doesn’t support comments. But why shouldn’t Atom prefer JSON5, which is a little bit more standard-orientated?
Speaking about standard-orientated: Maybe rework would be a good alternative to Less? It would fit the idea to work with modern web technologies like ES6 or Web Components, because you can forward polyfill some newish CSS specs. It also integrates very nicely with npm packaging!

I have no problem supporting CS (or TypeScript or something else) at all. But I would do it the other way around. Instead of making every example in the docs in CS/CSON and noting that JS/JSON could be used, too, in the last paragraph, make JS/JSON the default language - and note that you can use other languages like CS/CSON, too. JS will always be the common denominator.

Bottom line:

Please consider using more standard-orientated and future-orientated technologies in all docs and modules (be it a core module or something else).


FAQ: Best Practices
Archived FAQs (see FAQ category for all current FAQs)
#10

I agree whole heartedly with TJ.

Maintainers of this tool should go read the discourse conversation about CoffeeScript painting itself into semantic corners, locking itself to ES3/5.


#11

Respectfully disagree. I saw coffeescript and immediately threw my hands up.


#12

That’s fine. But I definitely have to ask why.


#13

Without having looked at the code, I can point out one reason to use CoffeeScript instead of vanilla JS: Literate CoffeeScript makes for easy documentation.

Also CoffeeScript is necessarily compiled down to JS, so I don’t see CS causing me any insurmountable troubles. I’ll still be able to extend the editor with JS

I’d still prefer the developers had used vanilla JS or ES6.


#14

In GitHub’s JavaScript Style Guide:

Write new JS in CoffeeScript.

and

Avoid adding new .js files.

So I think CoffeeScript is very reasonable choice of their own. But we can always develop plugins with JavaScript.


#15

Choosing coffee script in core will certainly impact contributions. I think it’s a short sighted and lazy choice.


#16

I respectfully disagree.

I personally much prefer CoffeeScript to JavaScript, both for readability and development speed. I am much more likely to hack on a CoffeeScript project than a JavaScript project. So while CoffeeScript may discourage some it will encourage others. It’s impossible to know what the net impact will be. So, if using CoffeeScript helps them ship, go for it!

I also would not be calling GitHub lazy as they clearly are not. (When was the last time any of us made something as awesome as Atom?) Being a jerk doesn’t help make your point.


#17

My comment was regarding the choice, not Github as a whole.


#18

I disagree too. IMHO Coffeescript increases code readability, and the core must be clean. Even if raising the entry barrier for new core developers, the contributions may have higher quality, easier to read and easier to maintain.


#19

To be honest, I would rather see them use something like YAML instead, which is also adapted outside of the CoffeeScript world…


#20

The good thing is that if the decision were made later to use vanilla javascript, doing so is very easy - you just compile.