Why some synchronous library in nodejs stick to use callback?

I'm a new nodejs developer, and开发者_运维问答 I think that I understand designs of nodejs.

I can understand that some syscall-related library should be asynchronous. These job will be queued and processed in different thread pool, and notified via callback when it finished.

However, I can't understand why some non-syscall related libraries are using callback as a communication method. For example, xml2js library is written in Javascript, and apparently, there is no reason that this parse function will return status via callback. It can return processing result directly, and code readability will be increased.

My question is, is there any reason that some nodejs library designers are sticking to callback-based communication instead of just using return value?

There is nothing wrong with the callback style.

var return = doSomething();
...

doSomething(function(return) {
    ...
});

This is preference. They're both valid. The former only seems "better" because you're used to it.

One good reason for the latter is that the API doesn't have to change when you change your library to be non-blocking.

People need to be reminded that node is a low level non blocking IO library. If you're going to do something like js2xml then clearly you're waiting for node 0.6 to standardise the web worker sub process API so you can send the heavy lifting to a sub proccess and do the actual hard work in a non blocking fashion.

To do this in a non blocking manner your API needs to be asynchronous (or you need it build into the language).

If its not asyncronous there is no reason to use a callback to pass the return value.

I've seen some libraries using callbacks instead of returns just to pass the errors back, although, in my opinion, using throws is better and cleaner.

Actually in terms of the LibXML parser implementation. Are you sure that there is no System-Level IO going on ever?

Think about the scenario where the XML you parse contains a DTD or Schema. What about XInclude processing that is often done in XML-Parsers.

Though there is no fundamental reason, to have an API that does not use any Low-Level IO functions to use the async-callback style, you don't always know whether there are not situations where IO actually might take place.

Now assume that you know your XML-Parser does not do any IO, because it does not handle XInclude and DTD/Schema validation. If you therefore decide to go the "traditional" return value route, then you will never be able to implement XInclude Processing or Schema validation without changing your API.

So often if you are writing an API you are better of going async/callback from the beginning, because you never know what you want to do later on.

Callbacks can be useful in various scenarios, for example when you are iterating through some collection (which is encapsulated for some reason):

function Foo() {
    this._data = [1, 2, 3, 4, 5]; 
}

Foo.prototype.forEach = function(callback) {
    var i, 
        len = this._data.length;

    for(i = 0; i < len; i++) {
        callback("Item number: " + this._data[i]);
    }
}

var foo = new Foo();

foo.forEach(function(item) {
    console.log(item);
});