Why coffeescript?


#45

To be frank - CoffeeScript/JavaScript isn’t fast enough. It also doesn’t integrate super well with the local file system. The editor is never going to feel right in terms of speed and it will carry with it all the limitations of JavaScript (not that I’m a hater of JavaScript of course). However, there ARE limitations and I think a code editor would be something that would be affected by such limitations. I do think it was a poor language choice.

If the core is really powered by JS here (and not just extensible via JS - I haven’t been able to research this enough to know how it works, it’s not exactly clearly stated in big bold print either), then I think it’s at a major disadvantage. What problem are we solving anyway? We already have “web based IDEs” too… So this will have extensibility and some other clever features? Ok…But that’s then nothing other people couldn’t implement with the flick of the wrist. Don’t get me wrong, a very large portion of the web is going to use Atom.io purely because it’s built by GitHub. …But let’s be clear… That is going to be the main driving reason why people use it. Trust in GitHub…And I must say that it certainly peaks my interest and I will also give it a try.

So if not CoffeeScript, then what? ES6 like asked? Node.js? Nope, not those either. You’re still talking about the same limitations. Python like SublimeText? Maybe…But it misses the goals of the authors, right? You want something more web native. You also want something that looks toward the future…And this is where I believe there were better choices (and who knows maybe they weren’t even known to the authors).

So my two cents?
Dart. TypeScript.

Best of both worlds here. First off you can compile down to normal JavaScript for that portability/cross platform support factor. Second, these next generation languages free you from the limitations of JavaScript - which I believe in this case would be problematic.

I think Spark is going to really give Atom a run for its money too because it’s built by Google which also has a trusted name.

So I’m super excited to see all these new editors take off because while I love SublimeText and while it does everything I need (which begs the question what “problem” do these new editors solve? Not much of one really), I am always eager to try out something new.

Very exciting stuff…Even if it is using CoffeeScript which I believe is the biggest waste of time. Don’t like JavaScript? Guess what? We got solutions for that and CoffeeScript ain’t one. But whatever, I still can’t wait to see Atom!


#46

You can (and Atom does) use C/C++ in node.js modules to speed things up if necessary or to use C/C++ libraries from JavaScript/CoffeeScript. Only the actual text editing part could get tricky. There are lots of tricks to make it fast, CodeMirror works pretty well and is used in lots of high profile projects (Google Chrome, Brackets, etc.), but making it as fast as a native text editor is a tough problem to solve and from what I’ve heard Github created their own text editing component instead of improving CodeMirror, so it’s going to be interesting to see how that works out for them. So far, it looks like people are complaining about the text editing speed (typing and scrolling), so that’s something they’ll have to improve for sure.

Dart would have been an interesting choice, it’s a language I’m very interested in right now myself since some really great people work on it including Gilad Bracha who also sneaked in some stuff from his Newspeak language, but it’s of course not very popular (who knows if Google isn’t going to abandon it completely at some point, they do have a bad track record with that) and then you couldn’t have easily written packages in JavaScript since it’s quite involved to use Dart together with JavaScript, you need to use proxy objects and that kind of stuff, you can’t use it directly as you can do with CoffeeScript (unless that has changed recently, didn’t have time to use it over the last few months).

Also, Dart and TypeScript didn’t even exist when Github started developing Atom, they are both really new languages and work on Atom has started about 6 years ago. Dart 1.0 was only released a few months ago, there were lots of backwards incompatible changes made to the language before 1.0 and there still are many more backwards incompatible changes to be expected for the libraries, especially the UI library which was completely replaced a few months ago.

We’ll see how it works out. At any rate, they aren’t going to switch from CoffeeScript to another language this late in the development process anyhow and CoffeeScript was a great choice in my opinion.


#47

6 years?! Wowsers.
Yea, I’ll be real interested to see how they handle the typing performance. I think that’s ones of those make it or break it things. An editor has to do its primary job well. Otherwise it could be useful in many cases but not for dedicated used.

Dart has come a long way and will continue to get better. I don’t think calling methods and such from JS to Dart is all that bad…importing JSON objects, etc.

I also would have a pretty big concern about it sticking around…no one will put the VM in their browser to be frank. Just Chrome. But… And it’s a big but…Dart is a lot faster than V8 and such. Especially at certain things, it smokes Node.js (not everything yet). Dart was specifically created because they have hit the ceiling with JavaScript. There’s not much more that can be done (no major single thing at least) to significantly increase performance. It also runs server side… So for that reason, I see Dart sticking around.

My question is how long will it take all the Node.js people to convert? Will they? I like my Node.js…and there’s so many packages for me to use with node. Its going to be a long time before Dart picks up the adoption, but I think it will when the limitations of JavaScript start mounting up more.

…and that’s why I was curious to see the approach of Atom. Build for today? Or build for tomorrow? …though given its age I totally get it and get the CoffeeScript.


#48

Not exactly the ceiling, but Google said there won’t be any amazing “x times faster than before” kind of improvements to JavaScript speed anymore and Google would know, they have some really talented and experienced virtual machine developers working for them. And as you alluded to, Dart is a language specifically created to be fast when running inside of a VM. But yeah, none of the big browser vendors (except for Google of course) has shown any interest in it at all, not even Mozilla.

You seem to have the exact same view of the situation with Dart as I do :slight_smile: I think what dampens the popularity of Dart is that most people don’t really know what it is. They think it’s just a language, a boring one at that since it uses no fancy new syntax, but it’s much more than that and even a complete replacement for node.js, which is problematic as you have said since node.js is so popular that not many people are going to be crazy about having to switch to something different.

And since the first public release which really was quite boring, there were many new awesome and exciting features added to the language. I think it would have been better if Google had waited a bit longer before they announced Dart. When they did, the tech press was all over it. They’ve missed that opportunity. And it doesn’t help that both Dart and Go can be used for server side programming, lots of people were confused why Google works on competing technologies (the same happened with Chrome OS and Android). But who knows, everyone hated on Go at first and now it’s become quite popular it seems, maybe that’ll still happen with Dart as well.


#49

I see this as a huge storm in a teacup, it seems atom are really focusing external contribution around packages that can be JS anyway. Core contributions seem to be much more limited as core will be licensed under a restrictive license.


#50

@sam CS has already caused me numerous problems- see CoffeeScript __extends vs util.inherits (Inheritance in JS) for instance. CS was a poor choice for more than one reason.


#51

This is such an oft-repeated fallacy. The output of a large, non-trivial coffeescript compile is really atrocious JavaScript with quirky idioms that you’d never use if you were thinking in JavaScript in the first place.


#52

ES6? What ES6. Don’t say polyfills or Traceur. ES6. Where?


#53

Atom is using node.js and node.js supports some ES6 features with --harmony flag


#54

function myOpinion(){
var firstOpinion = “Is it really that hard to read this”;
var secondOpinion = “Is it really that much faster not typing 5 characters that is consistent with all popular languages since the begining of time?”;
var thridOpinion = “Since when did curely braces become such a hard thing to deal with over spaces?”;
var fourthOpinion = “Now we have another stupid reason to learn coffeeScript thanks”;
return “blah blah dumb dumb”;
}


#58

It is funny, this thread caused a big debate in our office on JS vs Coffeescript. I say live and let live. There is no way that coffeescript provides that much of a barrier to entry for contributors, they can write js and plug it into a converter if they want.

Anyway, we ended up blogging about Why Coffeescript too! Either way, I am pretty happy with Atom so far.


#59

I always cringe when someone adds another post to this topic :laughing: It’s nice to see the occasional laid back post :wink:

I’m glad to hear that it spawned a lot of discussion! It sounds like it was mostly civil :wink: Looking forward to reading the blog post.


#60

Sorry to cause another cringe … but isn’t the real question:

 "How will Coffeescript evolve to es6?"  

For me, the high order bit is Modules. But the rest of es6, especially the parts needing compilation help, is important too.

And I’m sad to say, the CS community appears to have no one revealing plans, other than “wait for all browsers to have es6”.


#61

Maybe that’s what is important here.
I’m tired of reading that I have to use ES6 feats today when in practices I have to deal with browsers that doesn’t support them at all, and that sometime doesn’t even support ES5 features (who is using Object.defineProperty in production today?), or reading that this is so neat and marvelous when most of it it’s just a poor rip-off of CoffeeScript/Python features (if ECMA didn’t screw up ES4 that is).
Ok, node guys can be excited about it (and I’m a node guy to some extent), but honestly, why should I bother using syntax/features that are either 1) not definitive, 2) not supported, when I have most of the syntactic sugar of es6 for free?
Modules and import are nice but do they really provide any value beyond what node+coffee offer? (async modules may be a nice addition, but it’s far to be a finalized spec)

And if the answer imply to use es6 polyfils and preprocess every thing, I fail to see why it could be considered as a better alternative as writing CoffeeScript today : one thing that most coffee opponents complain about being the need to preprocess everything and the overhead it creates when debugging, using a polyfil is exactly the same except you don’t gain anything in readability as your still stuck to the JS syntax anyway.


#62

Anyway, it would be difficult to go back with a big re-facto of the Atom core.
For those (including myself) who are not at ease to create packages in CoffeeScript, I have written a package JS generator : https://github.com/Nicolab/atom-package-js-generator


#63

I for one still prefer the elegance of CS. And especially that it is “safe”. (Well, our group decided to avoid being TOO elegant. There is a CSHint)

So here’s the question: GitHub has invested heavily in CS, both in terms of all new site development and in Atom. Do you think they’d abandon CS when they need es6 features? I doubt it.

And the one feature they need is Modules. It is the es6 “sleeper”, IMHO. It may not only unify AMD and CommonJS, but also WebComponents. And the es6 spec was clever enough to generalize the module loader with the System object.

Lets nag github for at least modules in CS!


#64

If you don’t like CoffeeScript, don’t agree that it is better or don’t really care, just install the CoffeeScript Be Gone package!


#66

If that was true, then it’s obviously no point in using CoffeeScript over JavaScript. It is different and it does increase the barrier. It did for me, and I’ve coded JavaScript for almost two decades soon (2017).

Coding utilizes your brains FAP, Fixed Action Patterns. You traing and train your body to more fluidly write the code you think about. Having two languages which is virtually the same, works against our own brains.


#67

Can you re-read what you posted? There is a point, syntax can be the difference between wanting to use a language and not wanting to use it. Look at how many people dislike Lisps because of all of the parens that are used.

I’ve used JavaScript a long time and I’ve had no problem picking up CoffeeScript and using JavaScript back and forth. It doesn’t matter how long you’ve been doing JavaScript, it matters what your preferences are.

Overall I’m going to say your argument against CoffeeScript seems very weak and that you don’t see that using CoffeeScript or JavaScript is strictly preference at this point since they can do the exact same things in a syntax that’s extraordinarily similar.

That being said, I prefer JavaScript over CoffeeScript at this point but still see the value in CoffeeScript.


#68

I would have preferred plain JavaScript in Core but it’s well-known that Ruby (and Python)-centric developers prefer Coffeescript because it’s more aesthetically similar to what they’re used to, so no surprises there.