Callback-based code will always be more complex than synchronous code (and I believe that's an objective observation), but please let's not go there.

My remark was against their "Keep your code small and light". Making your code lighter doesn't always make it faster. If you can get your code to do less (like, skipping memory-based sessions), that will make it faster. If all you're doing is avoiding complexity, there's no guarantee it will be perform better.

The proper way is to benchmark and profile. You can refactor your code based on developer happiness, but only try increase its performance based on objective data.

EDIT: I should probably clarify this (although it seems silly to have to do this on HN): I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.

Inside of an asynchronous framework where every call blocks all others (eg Node.js), callback-based code is almost always going to be the right choice. If you can't immediately produce the answer, don't wait. And if you can immediately produce the answer but it will take a while, break it up into multiple smaller computations so that you do not block.

If you are in a different environment, the arguments for/against become much different.

> I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.

Node doesn't really give you much of a choice. If something is going to take awhile then you will be using callbacks, it's that simple.