Why coffeescript?


#21

YAML is an even bigger turn-off for me than CoffeeScript. It’s (borderline) human-readable, but I don’t find it human-writeable. The spec is enormous compared to JSON, it’s far fussier about precise syntax, and its complexity of deserialization has led to security exploits.


#22

Well. The way atom’s CSON parser currently works (eval) is just as bad as the YAML issues of old :slight_smile:


#23

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.

I agree with @visionmedia. It seems logical if the closed source part was in coffeescript (or any other technology), but there seems too much dependence on coffeescript. For example: I couldn’t run apm test on test cases written in javascript because @atom’s test spechelper was looking for files ending -spec.coffee only (Apm test and *.js specs) :confused:


#24

I’m personally a fan of the coffeescript. I find it interesting that every time a large, public app, framework or library is written in coffeescript, haters crawl out of the woodwork to complain. @visionmedia , is there a conversation anywhere on the internet dissing coffeescript that you haven’t been part of?

The creators of atom chose coffeescript for a reason. Maybe several. Obviously one is that it is company policy. These sorts of internal style and technology decisions are , from my experience, generally made in an at least somewhat democratic manner. We can probably conclude that the githubbers working on Atom actually prefer coffeescript to javascript. Since they are the ones who will ultimately be writing the bulk of the code, and more importantly reading and maintaining the bulk of the code, I do not think it’s right that others would try to press their preferences on them.

Contributions are great, and the lifesblood of any project that attempts to be in whole or in part open source, but if the project is useful and well-made, contributions will come regardless of the language that it is written in.

I do think providing API examples and docs for people wanting to write plugins in javascript should be made available, and for a text editor, the plugin ecosystem is what matters the most. While TJ and others may have a fair point about coffeescript API’s being sometimes awkward to work with from javascript, I think we can trust github to get this right.

Personally, I’m gonna be writing plugins/etc in Opal , but I’m certainly not going to sit here and suggest they re-write the app in ruby! I think I could make a strong case for ruby making contributions from new users easier, even more readable code, and a number of other points. And ruby is certainly a larger, more mainstream language than coffeescript (of course I admit it doesn’t have the mindshare javascript has atm, but that isn’t the point). And if I did that, it would be ridiculous.

It’s equally ridiculous to suggest they change the codebase to any other language, even javascript.

If the editor is really good people will use it, and people will contribute. Let’s leave the devs to decide what to write it in. Then they will be happier and more productive, and we’ll be far more likely to get that amazing editor.

And sure, there are people right now saying stuff like:

I saw coffeescript and immediately threw my hands up.

But you know what, if that guy falls in love with the editor because it is awesome, and some bug in it begins to bother him enough, I’d bet 9 times out of 10, he’ll dive into the code anyways.

I also have to call bullshit on arguments against coffeescript based on this idea that it will be unable to be ES6 compatible. People say this sometimes as if javascript generated from coffeescript will not run on ES6 or something, which isn’t true. What is true is that some features of ES6, which parallel features already present in coffeescript, will not be directly usable from coffeescript, this means very little in actuality. I mean, really, why does this matter exactly? The coffeescript features fit coffeescript very well. In cases where the native js version performs better than the coffeescript version, there is nothing that says the coffeescript version cannot be implemented in terms of the ES6 syntax eventually, perhaps based on a compiler flag,

So, to sum up, I’m going to reword TJ’s statement: ES6 buys you very little (Coffeescript can already do many of it’s best tricks), and you lose a lot (namely readability, aesthetically pleasant code, etc). You should have realized javascript was the deprecated form of the language years ago, and already switched to coffeescript. Leave it to programmers to be stubborn though.


#25

I’m willing to bet, in respect to the docs, that with little effort they could allow one to choose between JS and Coffeescript in doc code examples by simply showing compiled JS. It’s not as pretty as hand crafted JS, but it’s both a learning resource (one could switch between CS and JS) and a way to lower the barrier somewhat.

I’m pretty excited Coffeescript is preferred, because it’s just better. Additionally, @edubkendo 's comment pretty much slays the issue.


#26

It’s obvious that it’s just a matter of preference if one likes Coffeescript or not. I doubt it would really create a barrier to contribute as a good Javascripter would easily be able to write some Coffeescript after quickly skimming the documentation.

I personally really like the choice and think the core and packages have very clean/readable code due to using Coffeescript.


#27

I certainly wouldn’t be afraid of writing a little bit of coffeescript if I needed to (half the fun of being a programmer is learning new things!). However, according to the below quote, it might lead to less contributions:

The above quote is taken from the Discourse thread about Discourse linked to by @sam


#28

A valid concern, however, that was what, a year ago now? Coffeescript is growing like mad. Combine that with the Big-Project-uses-this-and-so-should-you seal of approval and you’ve got something vaguely paralleling what node.js did for Javascript.


#29

I have to agree with the people here that are happy about CoffeeScript being used for Atom. Ever since I started using CoffeeScript I just can’t go back to writing plain JavaScript and it only took me about 10 minutes to start writing CoffeeScript since it’s really just a different syntax. And then you can spend another 20 minutes to learn some of the neat extras CoffeeScript has to offer, like list comprehension, ranges, destructuring assignment, etc.

So I don’t think there really is any barrier to entry with CoffeeScript. It only feels that way because learning a new language can be hard, but usually (the exception being paradigm shifts like going from OOP to functional or concatenative programming) only because of the standard library that you have to learn together with the language. But CoffeeScript doesn’t have one, it uses JavaScript’s so it’s really just the syntax that you have to learn. And it’s such a nice syntax. I love the significant whitespace, not because it saves you a few keystrokes, but because it makes it so much easier to swap things around and it just looks nicer, it’s easier to read through code.

And l can only agree with this, CoffeeScript is everywhere now:

The talk here (and in the linked discussion about Discourse deciding against CoffeeScript) about ES6 did make me wonder though, but then again, from what I’ve read a lot of the features in EC6 were actually inspired by CoffeeScript. But that is the most valid concern I’ve seen so far in my opinion, although I have to say I know pretty much nothing about ES6 and while I’ve written JavaScript for a few years now, I still consider myself a newbie, so I can’t really make an informed statement about this being as big a problem as some people say or not.

But in the end, I think edubkendo’s argument against complaining about CoffeeScript already wins this discussion anyhow (although I would have preferred a less aggressive tone :)). It’s Github’s language of choice, this is Github’s project, they should be allowed to use what they like best to develop it.


#30

Is this discussion really providing value? CoffeeScript is company policy for the creators, isn’t difficult to learn, is completely optional for plugin authors, and the project is open source and can be forked/rewritten in ES6 if anyone has that kind of time. I doubt the Atom authors would be inclined to start over, so I’m not sure what is to gain here other than voicing preferences, and that’s done already.


#31

If the core development team prefers CoffeeScript, the question should be - why would you not want CoffeeScript ? It’s still JavaScript and it’s easier to read for the core team. Prefer pure JavaScript ? Write your plugins in pure JavaScript…

Let’s not make this a purist discussion… x% people prefer JavaScript and y% will prefer CoffeeScript It is what it is. Enjoy the beautiful thing that atom is going to be.


#32

I find coffeescript to be harder to read then javascript. I like my curly braces. But like others have said its not like we can’t write our plugins in javascript.

I am curious though… For those of you that do like coffeescript, what other languages do you use? Or what languages did you use previously?


#33

Way too many to write down here, but I can tell you my favorite languages of all time apart from CoffeeScript: REBOL, Smalltalk-80, Objective-C, Ruby and Clojure. Other languages I used a lot (due to work or because it was the best tool for the job) are: Java, C++, Python, PHP and Real Basic. Languages I’m trying out right now but am still unsure about are Google’s Dart and Go.


#34

Interesting. I thought maybe it had to do with people having a background in a language in something like ruby or maybe python.


#35

I personally will take plain JS any day over coffeescript, and I have wrote a lot of CS at work, I just find JS less ambiguous and easier to read. But that is just my opinion.

The thing is that it doesn’t really matter a lot, I wish they have chosen JS but I can see why they use CS, at the end of the day if you can write JS you can also write CS.


#36

Github should look at their own data, seriously.
http://adambard.com/blog/top-github-languages-for-2013-so-far/

For 2013 the number of javascript repos outweigh coffeescript almost 24:1. And that’s up from 18:1 in 2012.


#37

First of all, let me say that I don’t consider CoffeeScript to be a bad thing. It confuses the hell out of me, but that’s me personally, and maybe it’s due to my programming background. I’ve only dabbled a little bit in Ruby, and I avoid Python like the plague. I come from a C, C++ and PHP background, even though I haven’t really touched them in years now. Most of my work is JavaScript these days.

I’ve spent a lot of time trying to understand JavaScript and how it works, and I think I did a pretty good job of it. Whenever I pick up CoffeeScript, I feel as if most of my understanding of JavaScript suddenly vanishes into thin air. I guess what I’m trying to say is, since I can do a lot of stuff in JS, learning CS always seems like a waste of time, so I give up, and just end up writing pure JS. I never had enough motivation to delve into it. I thought Atom might be that motivation, but it really wasn’t.

I like the idea of Atom, and I like what it represents, but I’m turned off by the current documentation and plugin examples which are all written in CoffeeScript. I don’t think I’m competent enough to judge GitHub’s choice of programming language due to my unfamiliarity with CS, but with the current documentation, I’m helpless when it comes to writing anything but the most basic of plugins.

My current editor of choice is Chocolat. It’s a bit obscure and there aren’t that many plugins for it, but when I need something, I can extend it myself, even though the documentation leaves a lot to be desired. Still, since the plugins (or mixins, as they’re called) are JS, I can figure it out on my own. As a side note, I also like its Tern implementation (something that didn’t work out so well with the ST2/3).

I think it would be wonderful if GitHub would supply us with a couple of example core plugins and maybe some kind of documentation (which I’m sure is coming once things normalize a bit) that is JS-oriented. I don’t think that would be too much to appease CoffeeScript haters/avoiders/illiterates. JS plugin examples might be even more important than documentation because a lot of us like learning stuff by taking things apart. :smile:

I think that’s a fairly simple way of ending a potentially volatile discussion (bordering on feud), not to mention that it would increase the number of potential contributors. Programmers can often be really particular about what they use and how they use it, and I find the best way to avoid conflicts is to offer them a choice, something that should be a no-brainer in this case.

Edit: Oh, @mokkabonna, the data on the number of CoffeeScript repos could be slightly off, because the way I understand it, GitHub categorizes repos based on the most dominant language inside the repo. Since a lot of CS repos also include compiled JS code, they could end up showing as JS repos because the amount of generated JS is usually longer than the original CS code. Somebody, please correct me if I’m wrong.


#38

Putting aside subjective points about readability, aesthetics and other “it’s just better” arguments, most of the good language stuff present CoffeeScript is in ES6 as well. But let’s not forget that with all that good and not that good stuff that CoffeeScript has, it brings a whole class of problems that simply don’t exist (or are less severe) when using JavaScript.

All these problems originate from one simple fact: CoffeeScript has to be compiled to JavaScript in order to be executed in browsers/nodejs. It obviously creates more “moving parts” (source files, steps in build process, debugging source maps, etc.) and a priory takes more time to get your source code executed. Our industry knows a lot of examples of a similar sacrifice being successful - for instance assembly language vs higher-order programming languages. The sacrifice in case of CoffeeScript would be easier to justify if it was bringing more than just syntactic sugar comparing to ES6 JavaScript. So the good and the bad parts of CoffeeScript as a language should really be compared to TypeScript or Opal or Kotlin (or tons of other languages that compile to JavaScript).

I didn’t know Github had the policy to use CoffeeScript and as many others in this thread I think it does create a barrier for contributors as JavaScript is and will be (especially ES6) in foreseeable future a “lingua franca”, while CoffeeScript is just a somewhat spread dialect.


#39

@aaronogle The language I currently work in is ruby, I have also written quite a bit of java (maybe more java than anything else) and a decent chunk of coffeescript. I’m currently learning go, and I’ve written a half dozen Sublime Text plugins in python.

Definitely dislike curly brackets though. I find they add a lot of noise and do nothing to clarify that proper indentation and empty lines can’t do just as well. Also, I really hate semi-colons. I try to avoid those in both English and code.


#40

Curlies are useful sometimes.