I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript (e.g. CoffeeScript's notion of a class, whereas JavaScript has none -- let go an embrace the prototypal object model). Further, most (if not all) of the examples of the problems with JavaScript are null and void. A language that combines paradigms? Most do. Sure, the name sucks, but that's hardly an issue.
I understand that syntax may be more convenient for some, but this is indirection, and is a source of complexity that may impede collaboration from other devs more familiar with JavaScript.
I think the opposite: people you get CoffeeScript are more likely those who really get JavaScript. It's turning JavaScript into the language it was supposed to before before the marketers got their hands on it and "javafied it".
Perhaps this isn't the best forum for such a philosophical debate, but the notion that because you have prototypes in JavaScript you don't have classes is just plain wrong.
Every single time you see JavaScript prototypes used effectively, you'll find that they follow a classical pattern: A constructor function serves as the class object from which new objects are instantiated. Syntax like instanceof ("object instanceof class") gives this away. So do all of the built-in JavaScript classes: String, Function, RegExp, Number...
If it's an abstract object that defines common properties for instances, it's a class object, regardless of what you choose to call it. JS prototypes just expose the implementation mechanism, and CoffeeScript just provides you with a convenient way to manipulate the prototype chain.
I prefer coffeescript for the reduced line noise, particularly around lambdas, loops/comprehensions, and object literals. I find the shorter lines and reduced line count* allows me to notice api flaws more easily, so I tend to do my api design in cs. I generally don't use the class construct unless the library I'm working with uses the same pattern (e.g. yui3). It's pretty much just syntactic sugar that simplifies the code at the expense of complicating the toolchain. I think it's worth it but I've met plenty of people who don't.
* In js->cs rewrites I usually wind up cutting the line count in half, but most of that is eliminating all the stray closing brackets on their own lines and collapsing if statements into single lines.
CoffeeScript is javascript so prototypal objects still work as expected. They just went ahead and threw in classes if you want them, since there are already many javascript libraries that provide them for people who either are used to / want classes or to make it easier to port existing code.
I have to say that by using cs I learned a lot more about js. Maybe for old js cats it doesnt matter, but I only used js occasionally before, and now it became one of my favorite languages (I use with node, and I write all my node stuff in cs).
One particular example that changed everything for me was the natural and simple way I could build the typical callback constructs with -> and => , so they almost look like blocks in ruby, and feel way more natural as a control construct, and I didnt have to stack lots of })}); and so on.
If you're rather new to something, the ease of use and the simplicity and readability speeden up the learning process extremely.
That being said, there are also a couple of things in cs that are kind of silly.. like using 'for i in my_array', but 'for k of my_dict', and stuff like that, that are really hard to debug.
Although, in terms of debugging, the fact that it gets compiled and possible errors are early detected and a canonical js is generated also saved me lot of time, in particular with IE ;-)
I'm personally of the opinion that prototype-based systems are superior to class-based systems in exactly the same way that gotos are superior to for loops.
Add to this the fact that JavaScript's prototype system isn't actually very flexible, and you're almost always better off to roll a class-based system on top of it.
I don't think many use CoffeeScript because they don't "get" JavaScript. I think they use CoffeeScript because it gives them a much better JavaScript and makes them more productive and "happy".
> I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript
I disagree with this (though I agree with the rest of your post). The people that like CoffeeScript (and StratifiedJS and other projects like ObjectiveJ) are generally people that do get JavaScript really well. They just want to make it better.
The problem with CoffeeScript and the others is that they are not JavaScript. CoffeeScript is pretty straightforward in that it hardly even looks like JS and just compiles down to it, but others pretend to be JS but introduce new structures that make them all completely different languages (and do source transformation using JS in the browser).
If you don't know the transformations and you don't know JS very well, all these languages on top of JS will leave you stranded the second something goes wrong anywhere in the stack.
I'd like to see JS adopt some core structures for concurrency, namespaces and more CommonJS stuff instead of adding let, generators and comprehensions - which are nice, but mostly just fluff because you can do all those using the core language already and they're details nobody really cares about.
Personally I think Coffeescript is a big step forward. A pity it will likely never gain enough momentum to see native implementations on the major browsers.
JavaScript itself doesn't embrace a prototypal model. When was the last time you cloned an object to create a new one in JS?
JavaScript's model is much closer to classes than prototypes. The only real significant difference is that unlike class systems, JavaScript allows inheriting both "methods" and "state" from its "class". Otherwise, the language works more or less like a class-based one.
Sure, as long as you already understand Javascript. Think of people who are learning, or middle managers that are hiring. It's a lot more of a thorn than you might think, because you're educated.
Is your only basis for feeling that people that like CoffeeScript don't "get" JavaScript the `class` syntax? If that's the case, it's a minor feature of CoffeeScript. I'd say the rest of the features it offers fall on the dynamic/functional side of things more than the strong+static typed/classical OOP side ( list comprehensions, splats, treating everything as an exression, etc.).
I agree with everything you are saying. Coffeescript really is for people who prefer a ruby/python syntax, and who just don't like javascript's syntax.
BEATUY IS IN THE EYE OF THE BEHOLDER people! Just because you find javascript 'ugly' and coffeescript 'beautiful' doesn't actually mean everyone agrees with you. I think Javascript is beautiful and I've been coding it for 14 years. I have no need to replace the syntax, or complicate my development tools, or make debugging any more complicated that it already is.
Coffeescript evangelists are like born-agains who try to convert every man woman or child to their newfound religion because their god is the true god. It's annoying really.
The biggest problem with CoffeeScript adoption is the administrative overhead required for novices to get it running. This means that most CoffeeScript projects are usually larger -- it just doesn't get used in small one-off things.
My company's product is a hosted CMS and we just tackled this problem (http://www.gethifi.com/blog/hosted-cms-coffeescript-support) by completely eliminating the workflow issue. You can use Coffee or JS and the system takes care of the rest for you.
I've found this to be a big help when working on smaller client sites. Often I just need to write a couple dozens lines of JS and it just isn't worth the hassle to do it in Coffee -- now it's gravy.
I started toying with CoffeeScript a while back for my own entertainment and found the administrative overhead was much less than I anticipated. I went from a clean slate to being up and running in like five minutes. Once I had node and CoffeeScript installed, it was just a single command-line to start a watch on my .coffee file and then I was back to "refresh browser window to see my changes" mode just like regular JS.
I've done my fair share of web programming. But JavaScript (for me) has always been to add the flash, not to write the app. In the past couple of months, I dove into Backbone.js, Sammy.js, etc. and while my JavaScript worked, it wasn't "the JavaScript way".
When I found CoffeeScript, I was very happy. But I've been moving back to more JavaScript recently because I've spent hours looking through the generated JavaScript and learned quite a bit from it. I did the same with my C compiler and x86 Assembly :) It's nice to read what the experts think the final product should look like.
So write some CoffeeScript, compile it, and learn some JavaScript from it.
If you can't debug in CoffeeScript, you can't take it seriously. Even meta-CSS frameworks suffer from this problem when there's errors you have to back-track through a whole layer.
Absolutely, but the idea here is a bit different. JavaScript is a language that we're stuck with for the entire foreseeable future of the web, for better or for worse ... and CoffeeScript is a conscious attempt to try and work within that limitation. Unless you're willing to take the significant performance hit of running an interpreter on top of JavaScript, you have to stick fairly close to JavaScript semantics.
That said, we certainly try to improve upon JS semantics, where it's possible to do so without a performance hit. Things like auto-lexical scoping, bound functions, chained comparisons and, most importantly, "everything is an expression", are all examples of this.
In this case, the semantics were already decided: CoffeeScript was intended to map transparently to JavaScript. Each change to semantics would add complexity to that mapping.
I've had trouble learning CoffeeScript due to the compiler not providing any help whatsoever when you make a mistake.
I was writing a web server that just wouldn't compile, looked the code over several times and eventually gave up and did it in javascript instead. Later found out that Gedit was displaying a tab that vim showed as just being a space. Never tested if that was the only problem or not.
Agreed. The compiler definitely isn't as helpful as it could be in giving information about errors. On the other hand, a lot of the errors it hits at compile-time are things you wouldn't have noticed until run-time if you were writing JavaScript.
I would love to see javascript turn into assembly language. Google has already done with with GWT with great improvements in productivity.
One question I had while reading this. Was there a technical reason why he didn't make a gem or toolkit in pure Ruby or Python that would then spit out Javascript?
I think this is closer to how GWT did it where you can write pure Java, and of course it then wouldn't require people to learn a new language.
The issue is Ruby/Python/Java's semantics don't map perfectly to JavaScript. As it says in the documentation, the golden rule of CoffeeScript is "It's just JavaScript".
For people who know JavaScript, it's not a new language-- just some syntactic sugar and a few bonus features.
I wonder if it's feasible to hack the javascript engines (v8, spidermonkey, ...) to support languages CoffeeScript? In case the answer is positive how come nobody's doing that?
I really wanted to like CoffeeScript but that it can't be metaprogrammed and serialized (easily) is a huge problem for a scripting language. I guess scripting was never the point of CoffeeScript, but a lot of what makes JavaScript so flexible is lost when you add a compile stage.
[+] [-] jherdman|15 years ago|reply
I understand that syntax may be more convenient for some, but this is indirection, and is a source of complexity that may impede collaboration from other devs more familiar with JavaScript.
[+] [-] mrspeaker|15 years ago|reply
In fact, Brendan Eich has taken a bunch of it's features and they will be included in the next version of JS (woot!): http://brendaneich.com/2011/01/harmony-of-my-dreams/
http://www.aminutewithbrendan.com/pages/20110131
[+] [-] jashkenas|15 years ago|reply
Every single time you see JavaScript prototypes used effectively, you'll find that they follow a classical pattern: A constructor function serves as the class object from which new objects are instantiated. Syntax like instanceof ("object instanceof class") gives this away. So do all of the built-in JavaScript classes: String, Function, RegExp, Number...
If it's an abstract object that defines common properties for instances, it's a class object, regardless of what you choose to call it. JS prototypes just expose the implementation mechanism, and CoffeeScript just provides you with a convenient way to manipulate the prototype chain.
[+] [-] grayrest|15 years ago|reply
* In js->cs rewrites I usually wind up cutting the line count in half, but most of that is eliminating all the stray closing brackets on their own lines and collapsing if statements into single lines.
[+] [-] MatthewPhillips|15 years ago|reply
[+] [-] hermanthegerman|15 years ago|reply
One particular example that changed everything for me was the natural and simple way I could build the typical callback constructs with -> and => , so they almost look like blocks in ruby, and feel way more natural as a control construct, and I didnt have to stack lots of })}); and so on.
If you're rather new to something, the ease of use and the simplicity and readability speeden up the learning process extremely.
That being said, there are also a couple of things in cs that are kind of silly.. like using 'for i in my_array', but 'for k of my_dict', and stuff like that, that are really hard to debug.
Although, in terms of debugging, the fact that it gets compiled and possible errors are early detected and a canonical js is generated also saved me lot of time, in particular with IE ;-)
[+] [-] curtis|15 years ago|reply
Add to this the fact that JavaScript's prototype system isn't actually very flexible, and you're almost always better off to roll a class-based system on top of it.
[+] [-] amix|15 years ago|reply
[+] [-] mpk|15 years ago|reply
I disagree with this (though I agree with the rest of your post). The people that like CoffeeScript (and StratifiedJS and other projects like ObjectiveJ) are generally people that do get JavaScript really well. They just want to make it better.
The problem with CoffeeScript and the others is that they are not JavaScript. CoffeeScript is pretty straightforward in that it hardly even looks like JS and just compiles down to it, but others pretend to be JS but introduce new structures that make them all completely different languages (and do source transformation using JS in the browser).
If you don't know the transformations and you don't know JS very well, all these languages on top of JS will leave you stranded the second something goes wrong anywhere in the stack.
I'd like to see JS adopt some core structures for concurrency, namespaces and more CommonJS stuff instead of adding let, generators and comprehensions - which are nice, but mostly just fluff because you can do all those using the core language already and they're details nobody really cares about.
[+] [-] jackfoxy|15 years ago|reply
Personally I think Coffeescript is a big step forward. A pity it will likely never gain enough momentum to see native implementations on the major browsers.
[+] [-] munificent|15 years ago|reply
JavaScript itself doesn't embrace a prototypal model. When was the last time you cloned an object to create a new one in JS?
JavaScript's model is much closer to classes than prototypes. The only real significant difference is that unlike class systems, JavaScript allows inheriting both "methods" and "state" from its "class". Otherwise, the language works more or less like a class-based one.
[+] [-] krainboltgreene|15 years ago|reply
[+] [-] amadiver|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] neimado|15 years ago|reply
BEATUY IS IN THE EYE OF THE BEHOLDER people! Just because you find javascript 'ugly' and coffeescript 'beautiful' doesn't actually mean everyone agrees with you. I think Javascript is beautiful and I've been coding it for 14 years. I have no need to replace the syntax, or complicate my development tools, or make debugging any more complicated that it already is.
Coffeescript evangelists are like born-agains who try to convert every man woman or child to their newfound religion because their god is the true god. It's annoying really.
[+] [-] JoelSutherland|15 years ago|reply
The biggest problem with CoffeeScript adoption is the administrative overhead required for novices to get it running. This means that most CoffeeScript projects are usually larger -- it just doesn't get used in small one-off things.
My company's product is a hosted CMS and we just tackled this problem (http://www.gethifi.com/blog/hosted-cms-coffeescript-support) by completely eliminating the workflow issue. You can use Coffee or JS and the system takes care of the rest for you.
I've found this to be a big help when working on smaller client sites. Often I just need to write a couple dozens lines of JS and it just isn't worth the hassle to do it in Coffee -- now it's gravy.
[+] [-] munificent|15 years ago|reply
[+] [-] nexneo|15 years ago|reply
Read original here, http://jashkenas.github.com/coffee-script/
[+] [-] justrudd|15 years ago|reply
When I found CoffeeScript, I was very happy. But I've been moving back to more JavaScript recently because I've spent hours looking through the generated JavaScript and learned quite a bit from it. I did the same with my C compiler and x86 Assembly :) It's nice to read what the experts think the final product should look like.
So write some CoffeeScript, compile it, and learn some JavaScript from it.
[+] [-] astrodust|15 years ago|reply
[+] [-] endtime|15 years ago|reply
[+] [-] derwiki|15 years ago|reply
[+] [-] davepeck|15 years ago|reply
What's with today's obsession over beautiful syntax? Shouldn't we strive for beautiful semantics, instead?
[+] [-] jashkenas|15 years ago|reply
That said, we certainly try to improve upon JS semantics, where it's possible to do so without a performance hit. Things like auto-lexical scoping, bound functions, chained comparisons and, most importantly, "everything is an expression", are all examples of this.
[+] [-] skymt|15 years ago|reply
[+] [-] rayiner|15 years ago|reply
[+] [-] seanalltogether|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] MatthewPhillips|15 years ago|reply
I was writing a web server that just wouldn't compile, looked the code over several times and eventually gave up and did it in javascript instead. Later found out that Gedit was displaying a tab that vim showed as just being a space. Never tested if that was the only problem or not.
[+] [-] TrevorBurnham|15 years ago|reply
[+] [-] barmstrong|15 years ago|reply
One question I had while reading this. Was there a technical reason why he didn't make a gem or toolkit in pure Ruby or Python that would then spit out Javascript?
I think this is closer to how GWT did it where you can write pure Java, and of course it then wouldn't require people to learn a new language.
[+] [-] oscilloscope|15 years ago|reply
For people who know JavaScript, it's not a new language-- just some syntactic sugar and a few bonus features.
[+] [-] knv|15 years ago|reply
[+] [-] dstein|15 years ago|reply
[+] [-] mrkurt|15 years ago|reply
[+] [-] btipling|15 years ago|reply
[+] [-] Almaviva|15 years ago|reply
[+] [-] jergosh|15 years ago|reply
[+] [-] larelli|15 years ago|reply