14

Recently while working on a Backbone.JS/jQuery/CoffeeScript project, I found myself in a mess of callback and timing issues. I needed to wait for something to complete before proceeding and found myself in a mess of nested callbacks ... which is confusing and hard to debug. Then I found 2 possible solutions jQuery deferred or IcedCoffeeScript

IcedCoffeeScript looks really easy, simply adding await & defer. However, I wonder if its there to stay? Only 2 questions here on StackOverflow? Not much talk about it compared to CoffeeScript

Another thing is whats the difference between the 2 methods, they seem to do mostly the same thing? Except in IcedCoffeeScript, it looks more like procedural code, and in jQuery deferred, it doesn't solve my mess of callbacks as much

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Jiew Meng
  • 84,767
  • 185
  • 495
  • 805
  • jQuery deferreds are a thing of beauty. Personally speaking, and partly because I don't use CS, I'd go with that. – Mitya Jul 08 '12 at 13:24

4 Answers4

18

These are very different technologies:

  • IcedCoffeeScript is a precompiler that extends CoffeeScript with the await and defer keywords that transform code for you so that you can write code in a synchronous style. In the generated JavaScript, await and defer produce nested functions.

  • jQuery Deferred (aka Promises) are a way of side-stepping callbacks altogether: Instead of taking a callback, an async function can return a Promise. You then attach callbacks to the Promise. It's a simple, but powerful technique. I devote a chapter to it in my book, Async JavaScript.

Each of these technologies works best with a certain kind of API. await and defer expect a function to take a single callback as its last argument. Promises work best when you have lots of other Promises in your app.

There's no magic bullet for dealing with async behavior in JavaScript. You need to understand callbacks, Promises, and PubSub (aka EventEmitters) and choose the best tool for each job. Even if you use IcedCoffeeScript (which is cool), there are still times when Promises will save you a huge amount of work.

I hope that helps. Check out my book, Async JavaScript, for much more information.

Trevor Burnham
  • 76,828
  • 33
  • 160
  • 196
  • "Promises work best when you have lots of other Promises in your app" is an interesting statement. Could you put some more meat on it please? – Roamer-1888 Feb 25 '15 at 17:47
17

I think IcedCoffeeScript is here to stay.

I plan on supporting it indefinitely, and am pretty regular in patching it against the mainline. I use it on almost all of my personal projects, and the site Combosaurus.com, an OkCupid Labs project just about to hit general release, is written in IcedCoffeeScript.

AdrieanKhisbe
  • 3,899
  • 8
  • 37
  • 45
Max Krohn
  • 509
  • 4
  • 7
4

I wrote a blog post about the differences between standard event callbacks, pub sub and deferreds, which might help you out:

Event Emitter, Pub Sub or Deferred Promises … which should you choose?

The intro reads:

The obvious answer to the question “should you choose an Event Emitter, Pub Sub or Deferred / Promises” is that it depends on what you are doing.

In this post I will explore a little about how each pattern works with (very) basic implementations, and then I’ll look at the reasons why you might choose one over another.

And the summary is:

Event Emitter is a real classic, and allows for good practices and control over things that happen; Pub Sub is more flexible for cross-component events; Deferred and Promises give a powerful way to handle callbacks.

Applying the summary to your problem - I would suggest that Deferred's and Promises would probably help you out a lot.

I don't know about you, but I found getting my head around how I would implement Deferred really helped me understand the intricacies of using it. I've included some sample code in the post too, which being (extremely) simple, might help you out when looking at someone else's more robust attempt.

pete otaqui
  • 1,432
  • 14
  • 11
2

Oh, I'd definitely rely on IcedCoffeeScript. If you like and use CoffeeScript syntax, you'll find out it simply "blends" naturally with it...

Regarding the project future, I had the same dilemma a while ago, but it looks like Maxwell Krohn is actively maintaining it and there's a growing community and awareness around it (ok, maybe not here on stackoverflow yet).

I've started using it last year and now I couldn't really imagine coding "real-life" apps without await and defer.

You can find a brief "protip" on elegant asynchronous control flow with ICS here and I also wrote a 5-parts ironically-titled article on using Node.js for generic web projects here mentioning ICS.

Ionut-Cristian Florescu
  • 1,798
  • 1
  • 10
  • 11