December 24, 2012

I don't want promises

The next lines are about this new thing going on in the Javascript community: Promises
Chainable promises
Useless, jQuery does it for efficiency gains; gains that don't exist here. Even the syntax is the same length and sometimes longer.
Promises throw errors if an error handler is not provided
Error handlers should be always provided; if it is your own custom library fix it; if it is not use an alternative it does or fix it yourself (and make a pull request if possible).
CommonJS promise proposal [1] compliant
Oh, standards. It would even more standard not to use this.
Promises can be used securely (as separate resolver/promise pairs in ocap situations)
Don't call that security, just, no. (... what the hell is ocap?)
when() - Normalization of sync (normal values) and async (promises)
You are a big boy now, you can handle the difference
all() - Create a promise that accumulate multiple concurrent promises (failed promises resolve to Error objects)
What is the problem with array.push?
allOrNone() - Ditto, but the first promise to fail causes the composition to fail as well
Or you could use, you know; the Javascript logical AND operator ( && )
first() - Find the first promise to be fulfilled in a group of promises
Let me help you there: Array.shift()
seq() - Sequentially execute a set of promise returning functions
Dev used nested callbacks, is super effective
delay() - Returns a promise that is fulfilled after a given amount of time
Dev used setTimeout, is super effective
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style, to one where your functions return a value, called a promise, which represents the eventual results of that operation.
Yeah, with the little overhead that absolutely everything will be required to be a goddamn promise. More "pleasent" is merely your subjective view and continues-passing style is better than adding a new level of complexity in the way Javascript is executed. If you need to throw an error save it in the first parameter in the callback, just like almost any Node.JS function does, is not that hard.
function(error, data){
    if(error)
    throw error;
}
And if you really have so much problems trying to get a proper stacktrace for Javascript exceptions you should try learning a little more about the library you are using; or if that fails there is a new Javascript feature in the making called "domains"; which will be like Javascript exceptions for dummies.

2 comments:

  1. > Useless, jQuery does it for efficiency gains; gains that don't exist here. Even the syntax is the same length and sometimes longer.

    The point of promises is not efficiency or shorter code, it is simpler async operation management for complex applications.

    > Error handlers should be always provided; if it is your own custom library fix it; if it is not use an alternative it does or fix it yourself (and make a pull request if possible).

    In an ideal world, many things "should" work the same way, but in practice, one benefits from a pattern that allows you to consistently manage errors, regardless of the code you are using.

    >Oh, standards. It would even more standard not to use this.

    Having an standard is a good thing, because it makes the pattern easier to learn and use for everyone in different context (Promises exist in the realm of jQuery, node, and Microsoft announced that for windows 8 applications, promises will be the recommended way of handling asynchronous operations). When you have to use the same pattern in different places, it is absolutely convenient that the implementations are very similar, if not the same.

    > What is the problem with array.push?
    > Or you could use, you know; the Javascript logical AND operator ( && )

    You are missing the point here, promises are for async code, you cannot use an AND operator when you don't have the results right there.

    > Dev used nested callbacks, is super effective

    Nested callbacks (aka "pyramid of doom") are a quick way to get to spaghetti code. the idea of promises is to decouple the code that makes the async call from the code that manages the result. Callbacks are good for small application, but try to do something bigger and decoupling is your friend.

    > Dev used setTimeout, is super effective

    Again the idea that motivated the creation of promises (in general, I'm not talking specifically about a library or even node), is to help managing multiple asynchronous calls. you can't easily do that with setTimeout.

    > function(error, data){
    if(error)
    throw error;
    }

    The creator of node decided to follow this pattern to mantain the node codebase at a low level, that is, he avoided to force developers to use the promises pattern, which is something I think was a good idea. But if one constructs an application on node, and your application makes a lot of asynchronous callbacks, that you need to manage simultaneously or sequentially, good luck organizing that code if your application is really complex without using the help of a well known pattern.

    ReplyDelete
  2. promises give me eyestrain and are ugly to look at imo - they don't provide any functionality that wasn't already there and seem counter to the basic object orientation goal of abstraction. In other words, I prefer handler routines to be visually separated from the initialization routines.

    I could see how people who prefer functional style programming might prefer them. I'm happy that this construct is available for them. There's already enough hype in this business. Let's not pretend that they are necessary or intrinsically superior.

    ReplyDelete

You can use [CODE][/CODE] to post Javascript code.
You can start a sentence with ">" to make a quotation.