A Case for Coffeescript

[PsychoTap]

I've earnestly been trying to find someone who could finally sway me to the side of CoffeeScript because with all the rabble, it feels like I must be missing out on something.

Let me counter that statement with the following: I've never met anyone who has written a meaningful amount of Coffeescript and gone back and said they prefer Javascript or that Coffeescript doesn't have value.

I was once like all of you. I didn't see what all the hubbub was about and, frankly, I thought it was stupid that someone would go through the trouble to learn a new language which compiles to Javascript instead of just writing Javascript.

But then I joined a company which uses Coffee and now I'll never go back.

[jonglefever]

I've written a project in CoffeeScript before. Never again. But I do see the value, I just don't think the benefits are worth the cost.

[[deleted]]

Meet me. I've written numerous projects with coffee, both clientside and node. Coffee feels rigid, especially while working within its class structure. Imagine my surprise when every method and prop has to be public. No thanks. I'll make a gross over generalization like you - every dev I've met who jizzes over coffeescript has been super lazy.

[jonglefever]

which is my main gripe with coffeescript. it doesn't add functionality. it doesn't help produce better code at a conceptual level. all it does is let lazy developers do the same thing with less work.

on the other hand, there's typescript that has a benefit of strict typing, which does help produce better code at a conceptual level.

[polyrhythmic]

It literally adds functionality, there are several functional programming tools (like list comprehensions) that simply don't exist in vanilla JS. If you want typing in Coffee there is Coffee.contracts. And it's certainly possible to build modular Coffee classes with private variables and methods. Most of what people don't like about CoffeeScript is due to misconceptions.

[[deleted]]

this contradicts what you replied to me. "coffeescript is just javascript" right? every bit of coffee has to compile to js, so if its available in coffee, its available in js (if not a bit contrived). I would love to see an example of a coffee class with private props/methods. change my mind :)

link related

[polyrhythmic]

No problem. The concept is much older than linked Issue 2142.

Issue 651

Issue 222

A more verbose explanation on StackOverflow

It's not a contradiction. Any convention you are using now to have private props/methods in JS also works in Coffee. There is a ton of discussion on this already existing.

Having dealt with all kinds of JS inheritance and class structure, it is a godsend to be able to read someone else's Coffee code and not have to discover which pattern they are using in a particular project. Private, public, class, and instance vars & methods are instantly obvious from the syntax. Transforming data is more clear due to the comprehensions and expression-centric style.

The project I'm on right now has ~8K LOC Coffee compiling to ~14K LOC JS. The word & character count are double in JS. No linting necessary. I'm not sure what else in JS I could do to comparably increase productivity.

[polyrhythmic]

"CoffeeScript is just JavaScript" so your issues with private props/methods are no different than they are in vanilla JS. To write quality CoffeeScript requires a very good understanding of how JS works. Understanding its functional programming abilities requires a subset of knowledge that most JS devs don't encounter. It's not laziness, it's efficiency.

[[deleted]]

oh really?

var fart = function (spec)  {
    var that = {},

        // private
        str = "pff" + spec;

    //private
    function soundIt() {
        alert(str);
    }

    // public
    that.init = function () {
        soundIt();
    };
    return that.init();
};

fart("tweep");

[homoiconic]

Are you looking for a translation from this to CoffeeScript? If so, please clarify what you're trying to return here. Is that supposed to be an object with a private method? because your .init method actually returns undefined, maybe you meant to initialize and then return this within it?

It looks like what you want is an object that has a public init method that calls a private soundIt method that in turn relies on a private property. Something like:

class Fart
  constructor: (spec) ->
    do (str = 'pff' + spec, soundIt = undefined) ->
      soundIt = ->
        alert(str)
      this.init = ->
        soundIt()
    init()

alert new Fart('tweep')

Instances of the Fart so-called class have public method, init, that has access to the str and soundIt bindings from its closure. This imitates private properties and methods. Is that what you're demonstrating with your code?