Jeff,
Surprisingly I didn't know that one, I've added it to benchmarks, it turned
out to be slower than jQuery's implementation, and what's weird and
disturbing is that running concurrent calls using When is slower than
queued calls one after
another: https://github.com/medikoo/deferred#performance
In terms of functionality its API looks fully compliant with Promise/A
spec. Deferred is not that strict in that case, Deferred is more function
centered, e.g. promise is function itself (it's promise.then).
Create defer (unresolved promise):
// Deferred
var def = deferred();
// When
var def = when.defer();
Create resolved promise with valid value:
// Deferred
var resolved = deferred(value);
// When
var resolved = when.resolve(value);
Create rejected promise:
// Deferred
var rejected = deferred(error);
// When
var rejected = when.reject(error);
When I look at other functionalities they are also solved bit differently,
but I think it's no point to describe every difference. If you're after
anything specific just ask, I'll be happy to explain :)
What I've noticed and what's not great with When (I would even say it's a
design error) is that API doesn't provide function that ends flow. This is
very important as otherwise you're locked in try clause and unexpected
error would be silent.
Imagine you're just after final value of obtained promise. Handle it with
When:
promise.then(function (value) {
// do something with value
// but.. any error that might happen here will be catch and silent
});
So we've got an issue, technically you can just handle it by calling then
on new promise that was returned, but why we actually need another promise
for that?.. and still it's not perfect:
promise.then(function (value) {
// do something with value
}).then(function () {}, function (err) {
throw err; // it won't work, it's again in try catch clause
});
So what you really need to do to expose eventual error is:
promise.then(function (value) {
// do something with value
}).then(function () {}, function (err) {
process.nextTick(function () {
throw err; // Finally thrown!
});
});
It's not great.
Q took that into account and provided end() function for that:
promise.then(function (value) {
// do something with value
}).end(); // any eventual error will be exposed
Still with Q we create that extra promise that we don't need and that
affects performance.
In Deferred I solved it by making end function with same signature as then:
promise.end(function (value) {
// do something with value
});
If onerror callback is not provided, eventual error will just throw. So no
extra (not needed) promise is created and any error either returned by
promise or thrown in success handler will be exposed, that's what you
should expect.
On Monday, October 1, 2012 7:41:56 PM UTC+2, Jeff Barczewski wrote:
>
> How does your new version compare against https://github.com/cujojs/when ?
>
> I heard about this from the lxjs but have not used it yet.
>
> It was said that it was compatible with jQuery.Deferred API, but also
> claims to be very fast.
>
> I guess next time you run your benchmarks, you might add it in to see how
> it compares.
>
> If you take a look at it, I'd be interested in your thoughts and where
> your module might excel versus the other.
>
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
