by ianbishop on 3/2/13, 10:27 PM with 84 comments
by Swizec on 3/2/13, 11:51 PM
They're just continuations, seriously, what's everyone's problem? You define a function, it gets access to the current scope, it defines the rest of the program flow.
If you feel like your code is nesting too deep, you define the function elsewhere and just reference it by name. Then you don't get access to the current scope.
Why is this so difficult to people?
by etrinh on 3/3/13, 12:00 AM
Let's say you have 3 ajax calls going in parallel. With $.when, you can attach callbacks to arbitrary groupings of those ajax calls (callback1 runs when ajax1 and ajax2 are done, but callback2 runs when ajax1 and ajax3 are done).
I first learned about promises in Trevor Burnham's excellent book Async Javascript (http://pragprog.com/book/tbajs/async-javascript) and it is still the best explanation of promises I've ever read. If you like this article and are interested in reading further about promises or the asynchronous nature of Javascript in general (both for browser and node.js), I highly recommend you check out this book.
by daleharvey on 3/3/13, 2:24 AM
I got to write some firefox only code recently and added a delay to a function by just adding
... some code
setTimeout(continueFun, 5000)
yield;
... more code
by digisth on 3/2/13, 11:57 PM
https://github.com/caolan/async
I've only used it with node.js, but it's supposed to work in web browsers as well.
It allows you to think a little more procedurally ("waterfall" is especially handy here) while writing CPS code. Very good.
by pkulak on 3/2/13, 11:55 PM
by harshaw on 3/3/13, 12:15 AM
You really need to read the Deferred implementation if you are going to use it. Otherwise you are asking for trouble long term. Of course, the other issue is that you may run into challenges explaining deferred's to your co-workers. :)
Twisted explored some cool ideas where you basically would write asynchronous code in an interative style using a blend of iterators and generators. Sadly until Javascript has those capabilities in every browser (and not just Firefox) I don't think it is possible.
by spion on 3/3/13, 11:00 AM
http://code.google.com/p/v8/issues/detail?id=2355
If v8 implements this, both Firefox and Chrome as well as node.js will have yield, enabling libraries like taskjs [1] to be used.
From taskjs.org:
spawn(function*() {
var data = yield $.ajax(url);
$('#result').html(data);
var status = $('#status').html('Download complete.');
yield status.fadeIn().promise();
yield sleep(2000);
status.fadeOut();
});
by estavaro on 3/3/13, 12:28 AM
Just transmitting data back and forth may play well to the strengths of your abstraction. But we have other uses with Timers that should also need such abstractions.
With Timers I have other needs like delaying the execution, resetting the delay countdown, stopping it before it executes it at all (like cancelling it), and finally with an Animation class I needed a way to finish executing a string of events in an instant in order to start a new animation. Also the Animation had other Animation versions at play that could need to be sped up before a new Animation started.
In .NET they seem to have a handy feature that waits the code to run before proceeding that comes into play with their .NET version of the Reactive Framework.
As far as I can tell, it's tough to really solve it. JavaScript doesn't have extra features like .NET does. We are more limited in what we can do. In Dart they have a version of this called Future that has been streamlined recently. As simple as it may seem to be, it comes with other related abstractions called Streams that altogether make it a bit daunting to escape from that hell only to land on the fire outright.
by tomlu on 3/2/13, 11:57 PM
by jart on 3/3/13, 1:53 AM
by lucian1900 on 3/3/13, 11:24 AM
by jj2 on 3/3/13, 12:48 PM
https://github.com/Sage/streamlinejs http://en.wikipedia.org/wiki/Continuation-passing_style
by iamwil on 3/3/13, 3:51 AM
There's a gotcha with the progress handler. If you try to call the progress handler before the progress handler actually gets a chance to attach itself outside the function, it'll never actually fire. Some of the bugs with using promises are rather subtle.
by cwiz on 3/3/13, 4:11 AM
As for pure JavaScript, dealing with callbacks is definitely not fun.
by Offler on 3/3/13, 3:55 PM
Here is a simple example in some Node.js code I've just written (I've never written any before this little project).
https://github.com/Offler/node-bundler/blob/master/lib/bundl...
As you can see you just need to write in an OO manner and use function.bind(this) and Bob's your uncle. Really don't get the difficulty.
by Too on 3/3/13, 9:02 AM
function getItem(id) {
return $.get("/api/item/" + id);
}
$.when(getItem(3), getItem(4)).then(handleSuccess, handleFailure);
Future prediction: Someone will create code similar to the one above but inside a for-loop calling getItem hundreds of times instead of just 2.
by moe on 3/3/13, 2:54 PM
by rorrr on 3/3/13, 6:16 AM
function createItem(item, successCallback, errorCallback) {
var req = $.post("/api/item", item);
req.success(successCallback);
req.error(errorCallback);
}
by bestest on 3/3/13, 12:28 AM
The methods and approaches jQuery provides should not be used as a mainframe to achieve your goal, they should only be used as helpers here and there if ever.