4 ms·

> You don't "Think in CoffeeScript," you "Think in JavaScript." Only you think in well-crafted JavaScript. Not true, if only because CoffeeScript includes clas

> You don't "Think in CoffeeScript," you "Think in JavaScript." Only you think in well-crafted JavaScript. Not true, if only because CoffeeScript includes classes as a language feature. In JavaScript it is a hack. This might change with EmcaScript.next, but for now that creates a significantly different way to design your code. Try writing a Batman.js app in JavaScript and you'll see what I mean. With await/defer possibly being merged into CS, we're going to see the languages diverge further in the future.

jacobolus 15y ago
You missed the rest of the essay, wherein Raganwald described how CoffeeScript “features” are a shorthand for common JavaScript design patterns, forcing everyone to use the same patterns in the same way. [In other words, he answered your specific comment at great length, rendering your criticism of one out-of-context quotation a bit weak, eh?] Specifically, most major JavaScript projects have some kind of class implementation which makes inheritance, creating new classes, &c. easier. Some of these are quite elegant, but they end up being annoying anyway, because each system is slightly different. CoffeeScript takes one particular pattern (which is thankfully compatible with the expectations of Google's Closure compiler) and gives it a shorthand, so that everyone writing CS code will be on the same page.
- MatthewPhillips 15y ago
  Class inheritance is not a common JavaScript design pattern. It's a hack, used by a minority of JavaScript developers, in a minority of projects. The crux of the argument is that when you write CoffeeScript you think in JavaScript. But I absolutely never think about overriding a parent function in JavaScript. In CoffeeScript this is actively encouraged. Like I said, as other ideas like await/defer become more mature (and are merged into mainline), we're going to see the design patterns diverge futher.
  - jashkenas 15y ago
    > But I absolutely never think about overriding a parent function > in JavaScript. In CoffeeScript this is actively encouraged. Unfortunately, if you never think about overriding a parent's implementation of a function in JavaScript -- all that means is that you willfully don't use prototypes. The famous "prototype chain", by which object-orientation in JavaScript is accomplished, is all about overriding versions of parent properties. > Class inheritance is not a common JavaScript design pattern. > It's a hack, used by a minority of JavaScript developers, > in a minority of projects. Nope, it's deeply ingrained in all object-oriented JavaScript that uses prototypes. What are the built-in String, Function, RegExp, Number, Array, and Object, if not classes?
    - MatthewPhillips 15y ago
      There are a half a dozen different implementations of class inheritance in JavaScript. However no one writing a JS library is going to ask the consumer to extend one of their objects. This is what inheritance is all about. In Java you extend everything. Backbone.js is the only popular JS library I can think of which has their users use this pattern. It doesn't make since most of the time because: 1) The use of the pattern is not common in the js community. 2) If someone does use the pattern, they might be using a different implementation. That you can override an Object's toString is not what we're talking about here jashkenas. We're talking about creating an Animal class and extending it with Horse.
      - munificent 15y ago
        > However no one writing a JS library is going to ask the consumer to extend one of their objects. Uh, if you're using the Closure libraries, you very likely are extending goog.Control or goog.Component. I don't know dojo, but from my brief perusal of the docs it looks like you do the same thing with dojo.declare. YUI seems to do the same with Widget. I'm not aware of a UI framework in JS that doesn't use inheritance from outside the library.
      - jashkenas 15y ago
        > 1) The use of the pattern is not common in the js community. The use of prototypes is ubiquitous in the JS community. There's no two ways about it. Unfortunately, the avoidance of prototypes is also a common anti-pattern in the JS community, simply because JavaScript prototypes are so awkward, fragile and verbose. Doing the wrong thing with JS prototypes is easier than doing the right thing, which leads many developers to simply throw up their hands, and write code like this instead: function makeHorse() { var horse = { walk: function(){ ... }, trot: function(){ ... }, canter: function(){ ... }, gallop: function(){ ... } }; return horse; }; ... which is terribly inefficient and wasteful of memory, and accomplishes nothing that a prototype couldn't do in a small fraction of the space and time.
  - jacobolus 15y ago
    > Class inheritance is not a common JavaScript design pattern. It's a hack, used by a minority of JavaScript developers, in a minority of projects. If you don’t like the way JavaScript’s prototypal inheritance works, take it up with Brendan Eich. You are simply wrong about the commonness of using prototypes though. Nearly every big JavaScript project is organized around extending and creating prototypes, and making instances via the `new` keyword. It’s only a few zealots who militate against using that feature... and to the detriment of their followers, who end up with code that is slow and a memory hog.

jacobolus 15y ago

You missed the rest of the essay, wherein Raganwald described how CoffeeScript “features” are a shorthand for common JavaScript design patterns, forcing everyone to use the same patterns in the same way. [In other words, he answered your specific comment at great length, rendering your criticism of one out-of-context quotation a bit weak, eh?] Specifically, most major JavaScript projects have some kind of class implementation which makes inheritance, creating new classes, &c. easier. Some of these are quite elegant, but they end up being annoying anyway, because each system is slightly different. CoffeeScript takes one particular pattern (which is thankfully compatible with the expectations of Google's Closure compiler) and gives it a shorthand, so that everyone writing CS code will be on the same page.

MatthewPhillips 15y ago
Class inheritance is not a common JavaScript design pattern. It's a hack, used by a minority of JavaScript developers, in a minority of projects. The crux of the argument is that when you write CoffeeScript you think in JavaScript. But I absolutely never think about overriding a parent function in JavaScript. In CoffeeScript this is actively encouraged. Like I said, as other ideas like await/defer become more mature (and are merged into mainline), we're going to see the design patterns diverge futher.
- jashkenas 15y ago
  > But I absolutely never think about overriding a parent function > in JavaScript. In CoffeeScript this is actively encouraged. Unfortunately, if you never think about overriding a parent's implementation of a function in JavaScript -- all that means is that you willfully don't use prototypes. The famous "prototype chain", by which object-orientation in JavaScript is accomplished, is all about overriding versions of parent properties. > Class inheritance is not a common JavaScript design pattern. > It's a hack, used by a minority of JavaScript developers, > in a minority of projects. Nope, it's deeply ingrained in all object-oriented JavaScript that uses prototypes. What are the built-in String, Function, RegExp, Number, Array, and Object, if not classes?
  - MatthewPhillips 15y ago
    There are a half a dozen different implementations of class inheritance in JavaScript. However no one writing a JS library is going to ask the consumer to extend one of their objects. This is what inheritance is all about. In Java you extend everything. Backbone.js is the only popular JS library I can think of which has their users use this pattern. It doesn't make since most of the time because: 1) The use of the pattern is not common in the js community. 2) If someone does use the pattern, they might be using a different implementation. That you can override an Object's toString is not what we're talking about here jashkenas. We're talking about creating an Animal class and extending it with Horse.
    - munificent 15y ago
      > However no one writing a JS library is going to ask the consumer to extend one of their objects. Uh, if you're using the Closure libraries, you very likely are extending goog.Control or goog.Component. I don't know dojo, but from my brief perusal of the docs it looks like you do the same thing with dojo.declare. YUI seems to do the same with Widget. I'm not aware of a UI framework in JS that doesn't use inheritance from outside the library.
    - jashkenas 15y ago
      > 1) The use of the pattern is not common in the js community. The use of prototypes is ubiquitous in the JS community. There's no two ways about it. Unfortunately, the avoidance of prototypes is also a common anti-pattern in the JS community, simply because JavaScript prototypes are so awkward, fragile and verbose. Doing the wrong thing with JS prototypes is easier than doing the right thing, which leads many developers to simply throw up their hands, and write code like this instead: function makeHorse() { var horse = { walk: function(){ ... }, trot: function(){ ... }, canter: function(){ ... }, gallop: function(){ ... } }; return horse; }; ... which is terribly inefficient and wasteful of memory, and accomplishes nothing that a prototype couldn't do in a small fraction of the space and time.
- jacobolus 15y ago
  > Class inheritance is not a common JavaScript design pattern. It's a hack, used by a minority of JavaScript developers, in a minority of projects. If you don’t like the way JavaScript’s prototypal inheritance works, take it up with Brendan Eich. You are simply wrong about the commonness of using prototypes though. Nearly every big JavaScript project is organized around extending and creating prototypes, and making instances via the `new` keyword. It’s only a few zealots who militate against using that feature... and to the detriment of their followers, who end up with code that is slow and a memory hog.