4 ms·

Defer: Taming asynchronous javascript with coffeescript

69 points by gfxmonk 16y ago

_delirium 16y ago
Apart from being a cool bit of tech, this is a really good writeup.
pc 16y ago
Nitpick: the beautiful thing about Smalltalk's continuation support is that it's not provided by the compiler. (As far as I know, Squeak still doesn't ship with continuation support built-in.) Despite this, because stack frames are first class objects in Smalltalk, it's very easy for the user to implement continuations. You just traverse the stack to capture the continuation, and switch stack frames with the continuation's in order to invoke it. The resulting Continuation class is almost improbably literal in its implementation. This is what frameworks like Seaside do.
- gfxmonk 16y ago
  Thanks, good point. I actually meant to reference scheme, not smalltalk - as I believe that's where continuations were first done. I believe it is provided by the runtime in scheme (but still, not the compiler). I've corrected the post now.
deleted 16y ago
[deleted]
Mathnerd314 16y ago
Why not call it callCC instead of defer? Aside: great intro to continuations, I now understand them!
- fserb 16y ago
  I think you almost answered your own question. callcc makes people have to understand continuations and is confusing, while "defer" fits better with the control flow that most people have in mind already.
axod 16y ago
Good intro to continuations, but just reinforces the reasons I dislike them and wouldn't use them. Also disagree about "What is asynchronous programming, and why is it so damn awkward?" It's not awkward in the least. Either you write your code to remember the things you need to remember, or you use something like continuations which will be pretty inefficient and ugly (IMHO).
- gfxmonk 16y ago
  I'd like to see an example of nontrivial asynchronous code that isn't at least a little awkward. continuations may well be inefficient, it depends on the runtime. `defer` does not implement real continuations, so that's largely irrelevant - there is no runtime overhead that you don't already have by writing your own callback functions. As for ugly, do you refer to the compiled output, or the source code? gcc outputs some pretty ugly assembly code; does it matter?
  - axod 16y ago
    I'm referring to the source code. Also though ugly in terms of "eugh this isn't going to run efficiently. Mem usage will be crappy etc" I've written a large amount of async code now, both in js and in java. I don't ever feel it's awkward, do you have an example of this awkwardness?
- ekidd 16y ago
  Continuations can certainly be ugly (under some circumstances), and difficult, too. But there's no reason why this particular implementation of continuations needs to be inefficient—it has a one-to-one mapping with ordinary asynchronous JavaScript, and it generates exactly the code you'd otherwise write by hand. Overall, I think this is a win for clarity. But I think the author should also transform functions that take a callback argument, and implicitly convert them to continuation style. Perhaps this could by adding the callback parameter automatically and transforming 'return' into a callback invocation? async function (x) { return x; } => function (x, callback) { callback(x); }
  - 16y ago
jashkenas 16y ago
For extra reading material for the curious, the history of the proposed implementation of "defer" in CoffeeScript: Part I: http://github.com/jashkenas/coffee-script/issues/issue/241 http://github.com/jashkenas/coffee-script/issues/issue/241 Part II: http://github.com/jashkenas/coffee-script/issues/issue/287 http://github.com/jashkenas/coffee-script/issues/issue/287 Part III: http://github.com/jashkenas/coffee-script/issues/issue/350 http://github.com/jashkenas/coffee-script/issues/issue/350 If you have a suggestion for how to handle the bits of "defer" that are still undecided, such as how to handle the "return" statement, and enforce a callback parameter, please feel free to add it to the third ticket.
cageface 16y ago
Things like Coffeescript and Objective-J make me nervous. Javascript is flawed certainly but building a completely new language on top of it feels too radical. An abstraction like that seems bound to be leaky and it doesn't seem like you'll ever completely escape working with other native JS pieces so why not stick to a single, common syntax with good tool support, tutorials, docs, libraries etc? Javascript's not that bad a language once you establish some conventions.
- mhd 16y ago
  I don't know where to draw the line exactly, but I wouldn't call them completely new languages. Coffeescript is basically another syntax for JavaScript and Objective-J adds a few bits of syntactic sugar. The latter, of course, is pretty equivalent to what Objective-C does to C, Coffeescript reminds me a bit of Ratfor. Considering the unstructured default nature of JavaScript and its flexibility, I would say that you can get much farther of the trodden path by just using certain libraries. Adapting to a different syntax that just expresses things slightly different/shorter than you'd usually do things isn't as hard as actually doing things a different way. Straightforward jquery written in Coffeescript should be easier to understand than code that heavily uses wu.js, underscore and/or js.class. Of course, Objective-J has both syntactic additions and a huge Library tacked on. It's more meant to people who already work with Cocoa, so that their adjustments have to be minimal than for people coming from JavaScript. Coffeescript doesn't really compare to that. It's actually pretty minimal, and you shouldn't have trouble using it with JavaScript libraries, unless they depend too much on certain syntactic stylings (I bet fab.js won't play nice).
  - cageface 16y ago
    Considering the unstructured default nature of JavaScript and its flexibility, I would say that you can get much farther of the trodden path by just using certain libraries. Wu.js (thanks for the link) still looks like Javascript to me and won't cause any problems with Firebug or Emacs. Coffeescript and Objective-J have a completely different syntax. I can believe that Coffeescript is easier to read but it doesn't seem like enough of a win to break tool support and to work in two completely different syntaxes (inevitably there will still be plain js to deal with in most projects). Objective-J seems even riskier. I can see the appeal for Cocoa people but you're really going all-in with that kind of framework.

69 points by gfxmonk 16y ago

Apart from being a cool bit of tech, this is a really good writeup.

pc 16y ago

Nitpick: the beautiful thing about Smalltalk's continuation support is that it's not provided by the compiler. (As far as I know, Squeak still doesn't ship with continuation support built-in.) Despite this, because stack frames are first class objects in Smalltalk, it's very easy for the user to implement continuations. You just traverse the stack to capture the continuation, and switch stack frames with the continuation's in order to invoke it. The resulting Continuation class is almost improbably literal in its implementation. This is what frameworks like Seaside do.

gfxmonk 16y ago
Thanks, good point. I actually meant to reference scheme, not smalltalk - as I believe that's where continuations were first done. I believe it is provided by the runtime in scheme (but still, not the compiler). I've corrected the post now.

deleted 16y ago

[deleted]

Mathnerd314 16y ago

Why not call it callCC instead of defer? Aside: great intro to continuations, I now understand them!

fserb 16y ago
I think you almost answered your own question. callcc makes people have to understand continuations and is confusing, while "defer" fits better with the control flow that most people have in mind already.

axod 16y ago

Good intro to continuations, but just reinforces the reasons I dislike them and wouldn't use them. Also disagree about "What is asynchronous programming, and why is it so damn awkward?" It's not awkward in the least. Either you write your code to remember the things you need to remember, or you use something like continuations which will be pretty inefficient and ugly (IMHO).

gfxmonk 16y ago
I'd like to see an example of nontrivial asynchronous code that isn't at least a little awkward. continuations may well be inefficient, it depends on the runtime. `defer` does not implement real continuations, so that's largely irrelevant - there is no runtime overhead that you don't already have by writing your own callback functions. As for ugly, do you refer to the compiled output, or the source code? gcc outputs some pretty ugly assembly code; does it matter?
- axod 16y ago
  I'm referring to the source code. Also though ugly in terms of "eugh this isn't going to run efficiently. Mem usage will be crappy etc" I've written a large amount of async code now, both in js and in java. I don't ever feel it's awkward, do you have an example of this awkwardness?
ekidd 16y ago
Continuations can certainly be ugly (under some circumstances), and difficult, too. But there's no reason why this particular implementation of continuations needs to be inefficient—it has a one-to-one mapping with ordinary asynchronous JavaScript, and it generates exactly the code you'd otherwise write by hand. Overall, I think this is a win for clarity. But I think the author should also transform functions that take a callback argument, and implicitly convert them to continuation style. Perhaps this could by adding the callback parameter automatically and transforming 'return' into a callback invocation? async function (x) { return x; } => function (x, callback) { callback(x); }
- 16y ago

jashkenas 16y ago

For extra reading material for the curious, the history of the proposed implementation of "defer" in CoffeeScript: Part I: http://github.com/jashkenas/coffee-script/issues/issue/241 http://github.com/jashkenas/coffee-script/issues/issue/241 Part II: http://github.com/jashkenas/coffee-script/issues/issue/287 http://github.com/jashkenas/coffee-script/issues/issue/287 Part III: http://github.com/jashkenas/coffee-script/issues/issue/350 http://github.com/jashkenas/coffee-script/issues/issue/350 If you have a suggestion for how to handle the bits of "defer" that are still undecided, such as how to handle the "return" statement, and enforce a callback parameter, please feel free to add it to the third ticket.

cageface 16y ago

Things like Coffeescript and Objective-J make me nervous. Javascript is flawed certainly but building a completely new language on top of it feels too radical. An abstraction like that seems bound to be leaky and it doesn't seem like you'll ever completely escape working with other native JS pieces so why not stick to a single, common syntax with good tool support, tutorials, docs, libraries etc? Javascript's not that bad a language once you establish some conventions.

mhd 16y ago
I don't know where to draw the line exactly, but I wouldn't call them completely new languages. Coffeescript is basically another syntax for JavaScript and Objective-J adds a few bits of syntactic sugar. The latter, of course, is pretty equivalent to what Objective-C does to C, Coffeescript reminds me a bit of Ratfor. Considering the unstructured default nature of JavaScript and its flexibility, I would say that you can get much farther of the trodden path by just using certain libraries. Adapting to a different syntax that just expresses things slightly different/shorter than you'd usually do things isn't as hard as actually doing things a different way. Straightforward jquery written in Coffeescript should be easier to understand than code that heavily uses wu.js, underscore and/or js.class. Of course, Objective-J has both syntactic additions and a huge Library tacked on. It's more meant to people who already work with Cocoa, so that their adjustments have to be minimal than for people coming from JavaScript. Coffeescript doesn't really compare to that. It's actually pretty minimal, and you shouldn't have trouble using it with JavaScript libraries, unless they depend too much on certain syntactic stylings (I bet fab.js won't play nice).
- cageface 16y ago
  Considering the unstructured default nature of JavaScript and its flexibility, I would say that you can get much farther of the trodden path by just using certain libraries. Wu.js (thanks for the link) still looks like Javascript to me and won't cause any problems with Firebug or Emacs. Coffeescript and Objective-J have a completely different syntax. I can believe that Coffeescript is easier to read but it doesn't seem like enough of a win to break tool support and to work in two completely different syntaxes (inevitably there will still be plain js to deal with in most projects). Objective-J seems even riskier. I can see the appeal for Cocoa people but you're really going all-in with that kind of framework.