Write logic, not mechanics

It's a bit misleading way to put it, but more or less correct when talking about client-side JavaScript. There are essentially no blocking calls, so a "synchronous" function in this context just means a normal function which directly returns a value and "asynchronous" means a function that takes a callback.

What the quoted bit boils down to is that any function that returns normally can be converted into a function that calls a callback, but not the other way around.

The lack of semicolons in the article's examples makes me uneasy...

It looks like a bunch of us have had the same idea for Node.js. I wrote for example this: https://github.com/drostie/ducky/blob/master/promises.js

I've abandoned it at this point for a very particular reason: operators don't work well in this phrasing. That is, the example case given in the above discussion:

    function makeView(templateURI, dataURI) {
        var template = readURI(templateURI),
            data = readURI(dataURI);
        return Mustache.render(template, data);
    }

...while it's not bad, also doesn't actually try to "write logic", in a post that's about "write logic, not mechanics."

What you really want to do is much more complicated because the example code starts to look ugly:

    var userPromise = db.getUser(data.session);
    return userPromise.attr("role").equals("admin").then(
        render(open("yay.xml"), db.send(data.request)),
        render(open("no_permissions.xml"), {})
    );

Don't get me wrong, I still like the idea and think that there might be a very promising way to do this sort of work in Node. Certainly I prefer those five lines to always writing:

    db.getUser(data.session, function (err, user) {
        if (err) return callback(err);
        if (user.role === "admin") {
            db.send(data.request, function (err, reply) {
                if (err) return callback(err);
                render_file("yay.xml", reply, callback);
            });
        } else {
            render_file("no_permissions.xml", {}, callback);
        }
    });

But as much as I really don't like that lame error stuff which breaks in a stiff wind, I also really want to be cautious about the exchange of these two lines:

    if (user.role === "admin") {
    
    userPromise.attr("role").equals("admin").then(

What we really want, I guess, is some sort of mesoscopic system -- we still want operators and familiar control structures from our "micro" world, but we also want lazy evaluations and so on from our "macro" framework. This is not impossible but it is hard to get right. If my "ducky" project moves forward it will probably look something like this:

    return db.getUser(data.session)(function (user) {
        return (user.role === admin) ? 
             render(open("yay.xml"), db.send(data.request)) :
             render(open("no_permissions.xml"), {})
    });

You bubble up the lazy constructs with returns, the error handling gets internalized within the lazy constructs, and the "control-method" invocation allows you to build an arbitrary control structure with whatever object you have right now.

I detect sarcasm. Especially given the headlines of the past week.

Constructive post though, thanks!

Sorry for confusion, I meant indeed a sync / async APIs. You could easily wrap sync function to give it an async API in order to chain with functions that had async APIs, but it's not really possible other way round (not in JS).