14 ms·

My Perception of CoffeeScript

82 points by activestylus 14y ago

lucian1900 14y ago
CoffeeScript's classes are the extend functionality in underscore/backbone. Perhaps they're misnamed a little, but they're extremely simple. Just read the generated code.
- cmwelsh 14y ago
  This is my favorite reply, because it's exactly right. No one is stopping you from mixing and matching paradigms either! You can extend CoffeeScript classes with extra mixins. I think CoffeeScript's class keyword does a great job at what it's trying to do: make all the complexities of prototypical inheritance accessible to the average person who just wants simple object-oriented classes. CoffeeScript is just JavaScript.
tinutinu 14y ago
'I agree with this' is not same as 'objective and balanced'.
- activestylus 14y ago
  True that - I actually disagree with his final conclusion, because you can still program functionally in CS. I embraced JS prototypes a long time ago and have no need for the OO magic offered by CS. That said I still prefer it for a good chunk of my development. Coffee vs JS rants typically degenerate into emotional outbursts, I was impressed by the author's overall restraint and advocacy for both approaches
- to3m 14y ago
  I assumed this was some kind of dry humour. Language comparisons are rarely objective and balanced.
blrblr 14y ago
It makes more sense for CoffeeScript to exists as an independent language, rather than as a JavaScript generator. The syntax is beautiful, it had potential; why be a difficult-to-debug JavaScript 'compiler' instead?
- daveid 14y ago
  Sorry, but wouldn't that defy the purpose? You can only use JavaScript client-side, and I assume it would take a lot of time, effort, and "why" to make browsers ship parsers for other languages.
- boothead 14y ago
  I'd hardly characterise coffeescript generated js as difficult to debug (even the OO flavoured bits). My experience and that of most others I've seen online is that the mapping from the js that you debug back to the coffeescript that generated is trivially done in your head.
  - MrUnknown 14y ago
    As someone who barely knows any JavaScript, but want to learn CoffeeScript (I know ruby, and they are similar), even I can do this.
- rimantas 14y ago
  I'd say this "difficult-to-debug" attitude comes from those who did not actually tried to work with CoffeeScript and just think that would be the case. We have a lot of code in it already and debugging was never an issue.
  - base698 14y ago
    +1 here too.
gmac 14y ago
The author has 3 main gripes: backticks to drop back to JS, the 'class' keyword, and the fat ('this'-preserving) arrow. But these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow. At which point you're left with, from where I'm sitting, a less noisy, more concise, more enjoyable way to program the web browser than plain JS.
- activestylus 14y ago
  Well stated, and I agree 100% it is a sort of blindspot for this article. That said I agree with him on a level that CS does encourage a sort of OO band-aid approach towards functional programming and will definitely impede newcomers from embracing the power that comes with the built-in paradigm. I feel that it should not be in core, but am happy as you are to simply use what works and ignore what doesnt
  - oscilloscope 14y ago
    Synapse creates a non-trivial Class: https://github.com/bruth/synapse/blob/master/src/synapse.coffee https://github.com/bruth/synapse/blob/master/src/synapse.cof... Here's the documentation, to get some context: http://bruth.github.com/synapse/docs/#learn http://bruth.github.com/synapse/docs/#learn Do you feel that this code would be significantly improved by using JavaScript's bare prototype pattern instead?
    - activestylus 14y ago
      ^ Thanks for sharing that. I hadn't heard of Synapse but its the most unobtrusive data-binding lib I've seen so far. Very cool indeed! As far as implementation goes, it still feels "wrong" to me. I love syntactic sugar when possible, but forcing one paradigm on another without measurable benefit (aside from one's comfort/preference) just seems superfluous to me. I would personally implement it using a modular FP pattern, you get constructors, private methods and all those juicy bits we love about OO, except we are in a completely functional state of mind. http://answers.oreilly.com/topic/2177-how-to-use-the-module-pattern-in-javascript/ http://answers.oreilly.com/topic/2177-how-to-use-the-module-... I'd much rather leverage the core strength of a language than try to force it to fit my own habits/patterns. That's just me though :)
smoyer 14y ago
And the next technical book to be published? ... "Coffeescript - The Good Parts" On a more serious note, I love Coffeescript and am adept at Javascript. But since we have both of them, I get to choose.
- wwweston 14y ago
  Then we can move on to inventing EspressoScript: It's the Good Parts of CoffeeScript, and not the bad!
  - smoyer 14y ago
    Which will of course be forked to LatteScript, CappacinoScript and MachiatoScript. Real non-conformists will insist on TeaScript (or its fork - ChaiScript). After years of infighting, the industry will finally get behind a standard based on the least common denominator - CaffeineScript which will prompty be sued out of existence by the Caffeine JVM (overlay on .NET?). By then, young developers will be so disillusioned with the whole process that they'll invent something totally different ... and who can blame them ;) Due to the vocal nature of its supporters, RubyRedGrapefruitScript becomes the default scripting language available in modern browsers. I'm glad I know assembly language ... I can always go back to the beginning ;)
    - jashkenas 14y ago
      As often happens, the truth is more interesting than the satire... Coco: https://github.com/satyr/coco https://github.com/satyr/coco LiveScript: http://gkz.github.com/LiveScript/ http://gkz.github.com/LiveScript/ IcedCoffeeScript: http://maxtaco.github.com/coffee-script/ http://maxtaco.github.com/coffee-script/ Parsec CoffeeScript: https://github.com/fab13n/parsec-coffee-script https://github.com/fab13n/parsec-coffee-script UberScript: https://github.com/jstrachan/coffee-script/blob/master/TypeAnnotations.md https://github.com/jstrachan/coffee-script/blob/master/TypeA... ToffeeScript: https://github.com/jiangmiao/toffee-script https://github.com/jiangmiao/toffee-script Kaffeine: http://weepy.github.com/kaffeine/ http://weepy.github.com/kaffeine/
stcredzero 14y ago
It’s not the that Object modeling metaphor used in CoffeeScript is bad, it’s just overly object-oriented and builds on OO style inheritance. There are lots of people who don't even include inheritance in their definitions of OO.
jashkenas 14y ago
This essay is fairly amazing -- there's so much emotion and so many assertions packed into it, and yet they're all founded on innuendo and hearsay, not on how things actually are. Most of the things Leon writes are factually incorrect, but at the same time, you can see how listening to enough FUD might make you start to think them... For example: > CoffeeScript classes have attributes and properties that > are encouraged to be mutated by reference so a language > contrivance was devised (@) to allow OO style encapsulation > while still trying to provide Functional referential > transparency in anonymous contexts… wrap your head around that. What? Instances of CoffeeScript classes are just like any other JavaScript object with a prototype -- just like any old string or function or array. The "language contrivance" `@` symbol is simply an alias for `this`. Nothing more and nothing less. `@name` in CoffeeScript is just `this.name` in JavaScript -- I'm not sure how you wind up with "functional referential transparency in anonymous contexts" from there ... but I'll have a little of whatever Leon's smoking ;) There's many other things in the essay, but the core boils down to this: There are a bunch of folks who are used to ignoring prototypes in JavaScript because they hand-roll objects by manually adding properties or using Crockford's "module pattern". For them, CoffeeScript's `class` keyword feels like it's adding something alien to JavaScript because it makes prototypes accessible. It's not. Using prototypes and objects lies at the core of JavaScript, and it's only the difficult and fragile syntax that leads people to manufacture new instances like this: var makeDog = function() { return { bark: function(){}, run: function(){}, ... }; }; Instead of the far more efficient: new Dog; Finally, CoffeeScript isn't encouraging you to do anything in particular. If you truly don't like using prototypes in JS, feel free not to use `class` in CS. > Jeremy Ashkenas, whom I do not know but would > LOVE to have a drink with (alcoholic drink or > otherwise) and pick his brain ... Ping me the next time you're in NYC. Always happy to grab a drink and talk shop.
- activestylus 14y ago
  Nice to have you chime in here Jeremy. I personally use CoffeeScript a lot. I also code in Ruby and understand its appeal from that perspective. However I am curious what your take is on dxbydt's reply below. He makes a very interesting comment about the overhead of objects vs simple message passing/currying/etc.
lazerwalker 14y ago
> If you’re a fan of OO you’re going to love CoffeeScript from day one, guaranteed. If you’ve never tried to see the world through Functional glasses then I assert that you’re going to be missing out on a few beautiful vistas. I feel like he's not using the same CoffeeScript I am. Yes, it does make OO-style programming easier than vanilla JS, but it also makes functional programming a heck of a lot more accessible. The terser function creation syntax and the 'everything is an expression' mindset might appear at first glance to be minor improvements, but they add up to a language where working in a functional paradigm is a lot more enjoyable than regular JS.
- base698 14y ago
  Not to mention it's based on underscore and has almost all the Lisp functions baked in. That coupled with less verbose function syntax and it's an FP programmers wet dream :)
- nilliams 14y ago
  Absolutely agree fp looks and feels great in CoffeeScript.
- LeonidasXIV 14y ago
  I have to agree with you here. Since using CS my code got far more functional because I could create functions that create functions really easy and the implicit returns make it feel like a functional language.
danso 14y ago
This may sound pedantic, but I wish that these type of technical screeds were created with the flexibility/power of online publishing in mind. There needs to be more thought given to the use of non-prose in communicating these things. More tables, a la Ed Tufte's principle of direct comparison and small multiples, is a huge help. At the very least, it helps break up dense text and forces the author to be more aware of how to best not bury important statements and assertions. But if you aren't going to go all-in and use tables/graphics because it's a bit of work...then at least use headings, bulleted lists, formatted-text...this is the web, after all. Or, if you don't even want to do that, at least use line breaks like everyone learns about. And if you plan on including code, please use a wide enough format (and of course, syntax highlighting, though that is additional overhead). I don't mean to belittle this author's point on the basis of visual cues alone. It's just that I see a lot of great essays that could be so much more influential and effective with just some additional effort put into presentation.

82 points by activestylus 14y ago

lucian1900 14y ago

CoffeeScript's classes are the extend functionality in underscore/backbone. Perhaps they're misnamed a little, but they're extremely simple. Just read the generated code.

cmwelsh 14y ago
This is my favorite reply, because it's exactly right. No one is stopping you from mixing and matching paradigms either! You can extend CoffeeScript classes with extra mixins. I think CoffeeScript's class keyword does a great job at what it's trying to do: make all the complexities of prototypical inheritance accessible to the average person who just wants simple object-oriented classes. CoffeeScript is just JavaScript.

tinutinu 14y ago

'I agree with this' is not same as 'objective and balanced'.

activestylus 14y ago
True that - I actually disagree with his final conclusion, because you can still program functionally in CS. I embraced JS prototypes a long time ago and have no need for the OO magic offered by CS. That said I still prefer it for a good chunk of my development. Coffee vs JS rants typically degenerate into emotional outbursts, I was impressed by the author's overall restraint and advocacy for both approaches
to3m 14y ago
I assumed this was some kind of dry humour. Language comparisons are rarely objective and balanced.

blrblr 14y ago

It makes more sense for CoffeeScript to exists as an independent language, rather than as a JavaScript generator. The syntax is beautiful, it had potential; why be a difficult-to-debug JavaScript 'compiler' instead?

daveid 14y ago
Sorry, but wouldn't that defy the purpose? You can only use JavaScript client-side, and I assume it would take a lot of time, effort, and "why" to make browsers ship parsers for other languages.
boothead 14y ago
I'd hardly characterise coffeescript generated js as difficult to debug (even the OO flavoured bits). My experience and that of most others I've seen online is that the mapping from the js that you debug back to the coffeescript that generated is trivially done in your head.
- MrUnknown 14y ago
  As someone who barely knows any JavaScript, but want to learn CoffeeScript (I know ruby, and they are similar), even I can do this.
rimantas 14y ago
I'd say this "difficult-to-debug" attitude comes from those who did not actually tried to work with CoffeeScript and just think that would be the case. We have a lot of code in it already and debugging was never an issue.
- base698 14y ago
  +1 here too.

gmac 14y ago

The author has 3 main gripes: backticks to drop back to JS, the 'class' keyword, and the fat ('this'-preserving) arrow. But these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow. At which point you're left with, from where I'm sitting, a less noisy, more concise, more enjoyable way to program the web browser than plain JS.

activestylus 14y ago
Well stated, and I agree 100% it is a sort of blindspot for this article. That said I agree with him on a level that CS does encourage a sort of OO band-aid approach towards functional programming and will definitely impede newcomers from embracing the power that comes with the built-in paradigm. I feel that it should not be in core, but am happy as you are to simply use what works and ignore what doesnt
- oscilloscope 14y ago
  Synapse creates a non-trivial Class: https://github.com/bruth/synapse/blob/master/src/synapse.coffee https://github.com/bruth/synapse/blob/master/src/synapse.cof... Here's the documentation, to get some context: http://bruth.github.com/synapse/docs/#learn http://bruth.github.com/synapse/docs/#learn Do you feel that this code would be significantly improved by using JavaScript's bare prototype pattern instead?
  - activestylus 14y ago
    ^ Thanks for sharing that. I hadn't heard of Synapse but its the most unobtrusive data-binding lib I've seen so far. Very cool indeed! As far as implementation goes, it still feels "wrong" to me. I love syntactic sugar when possible, but forcing one paradigm on another without measurable benefit (aside from one's comfort/preference) just seems superfluous to me. I would personally implement it using a modular FP pattern, you get constructors, private methods and all those juicy bits we love about OO, except we are in a completely functional state of mind. http://answers.oreilly.com/topic/2177-how-to-use-the-module-pattern-in-javascript/ http://answers.oreilly.com/topic/2177-how-to-use-the-module-... I'd much rather leverage the core strength of a language than try to force it to fit my own habits/patterns. That's just me though :)

smoyer 14y ago

And the next technical book to be published? ... "Coffeescript - The Good Parts" On a more serious note, I love Coffeescript and am adept at Javascript. But since we have both of them, I get to choose.

wwweston 14y ago
Then we can move on to inventing EspressoScript: It's the Good Parts of CoffeeScript, and not the bad!
- smoyer 14y ago
  Which will of course be forked to LatteScript, CappacinoScript and MachiatoScript. Real non-conformists will insist on TeaScript (or its fork - ChaiScript). After years of infighting, the industry will finally get behind a standard based on the least common denominator - CaffeineScript which will prompty be sued out of existence by the Caffeine JVM (overlay on .NET?). By then, young developers will be so disillusioned with the whole process that they'll invent something totally different ... and who can blame them ;) Due to the vocal nature of its supporters, RubyRedGrapefruitScript becomes the default scripting language available in modern browsers. I'm glad I know assembly language ... I can always go back to the beginning ;)
  - jashkenas 14y ago
    As often happens, the truth is more interesting than the satire... Coco: https://github.com/satyr/coco https://github.com/satyr/coco LiveScript: http://gkz.github.com/LiveScript/ http://gkz.github.com/LiveScript/ IcedCoffeeScript: http://maxtaco.github.com/coffee-script/ http://maxtaco.github.com/coffee-script/ Parsec CoffeeScript: https://github.com/fab13n/parsec-coffee-script https://github.com/fab13n/parsec-coffee-script UberScript: https://github.com/jstrachan/coffee-script/blob/master/TypeAnnotations.md https://github.com/jstrachan/coffee-script/blob/master/TypeA... ToffeeScript: https://github.com/jiangmiao/toffee-script https://github.com/jiangmiao/toffee-script Kaffeine: http://weepy.github.com/kaffeine/ http://weepy.github.com/kaffeine/

stcredzero 14y ago

It’s not the that Object modeling metaphor used in CoffeeScript is bad, it’s just overly object-oriented and builds on OO style inheritance. There are lots of people who don't even include inheritance in their definitions of OO.

jashkenas 14y ago

This essay is fairly amazing -- there's so much emotion and so many assertions packed into it, and yet they're all founded on innuendo and hearsay, not on how things actually are. Most of the things Leon writes are factually incorrect, but at the same time, you can see how listening to enough FUD might make you start to think them... For example: > CoffeeScript classes have attributes and properties that > are encouraged to be mutated by reference so a language > contrivance was devised (@) to allow OO style encapsulation > while still trying to provide Functional referential > transparency in anonymous contexts… wrap your head around that. What? Instances of CoffeeScript classes are just like any other JavaScript object with a prototype -- just like any old string or function or array. The "language contrivance" `@` symbol is simply an alias for `this`. Nothing more and nothing less. `@name` in CoffeeScript is just `this.name` in JavaScript -- I'm not sure how you wind up with "functional referential transparency in anonymous contexts" from there ... but I'll have a little of whatever Leon's smoking ;) There's many other things in the essay, but the core boils down to this: There are a bunch of folks who are used to ignoring prototypes in JavaScript because they hand-roll objects by manually adding properties or using Crockford's "module pattern". For them, CoffeeScript's `class` keyword feels like it's adding something alien to JavaScript because it makes prototypes accessible. It's not. Using prototypes and objects lies at the core of JavaScript, and it's only the difficult and fragile syntax that leads people to manufacture new instances like this: var makeDog = function() { return { bark: function(){}, run: function(){}, ... }; }; Instead of the far more efficient: new Dog; Finally, CoffeeScript isn't encouraging you to do anything in particular. If you truly don't like using prototypes in JS, feel free not to use `class` in CS. > Jeremy Ashkenas, whom I do not know but would > LOVE to have a drink with (alcoholic drink or > otherwise) and pick his brain ... Ping me the next time you're in NYC. Always happy to grab a drink and talk shop.

activestylus 14y ago
Nice to have you chime in here Jeremy. I personally use CoffeeScript a lot. I also code in Ruby and understand its appeal from that perspective. However I am curious what your take is on dxbydt's reply below. He makes a very interesting comment about the overhead of objects vs simple message passing/currying/etc.

lazerwalker 14y ago

> If you’re a fan of OO you’re going to love CoffeeScript from day one, guaranteed. If you’ve never tried to see the world through Functional glasses then I assert that you’re going to be missing out on a few beautiful vistas. I feel like he's not using the same CoffeeScript I am. Yes, it does make OO-style programming easier than vanilla JS, but it also makes functional programming a heck of a lot more accessible. The terser function creation syntax and the 'everything is an expression' mindset might appear at first glance to be minor improvements, but they add up to a language where working in a functional paradigm is a lot more enjoyable than regular JS.

base698 14y ago
Not to mention it's based on underscore and has almost all the Lisp functions baked in. That coupled with less verbose function syntax and it's an FP programmers wet dream :)
nilliams 14y ago
Absolutely agree fp looks and feels great in CoffeeScript.
LeonidasXIV 14y ago
I have to agree with you here. Since using CS my code got far more functional because I could create functions that create functions really easy and the implicit returns make it feel like a functional language.

danso 14y ago

This may sound pedantic, but I wish that these type of technical screeds were created with the flexibility/power of online publishing in mind. There needs to be more thought given to the use of non-prose in communicating these things. More tables, a la Ed Tufte's principle of direct comparison and small multiples, is a huge help. At the very least, it helps break up dense text and forces the author to be more aware of how to best not bury important statements and assertions. But if you aren't going to go all-in and use tables/graphics because it's a bit of work...then at least use headings, bulleted lists, formatted-text...this is the web, after all. Or, if you don't even want to do that, at least use line breaks like everyone learns about. And if you plan on including code, please use a wide enough format (and of course, syntax highlighting, though that is additional overhead). I don't mean to belittle this author's point on the basis of visual cues alone. It's just that I see a lot of great essays that could be so much more influential and effective with just some additional effort put into presentation.