Threads are not a menace if implemented correctly. Note how almost every evented system is written in a language with horrible threads support, e.g. Python. Tak

Threads are not a menace if implemented correctly. Note how almost every evented system is written in a language with horrible threads support, e.g. Python. Take a language like Go or Haskell, and threads become a highly performant (by virtue of transparently asynchronous I/O operations) means of writing code with many threads of control, and saves you from getting bundled up in callback spaghetti. (I love Twisted, but I really don't miss the callback spaghetti it inevitably causes. InlineCallbacks made it nicer, but it was still a pain.) If you absolutely want to use JavaScript, then yes, you'll be writing event-driven code using a continuation passing style. JavaScript is probably one of the better languages for doing so, since the language is fundamentally single-threaded, and so virtually everything is asynchronous. The biggest argument for this is that you don't have to worry about synchronization. But please don't imply that event-driven programming is The One Way, or even the right way at all. If you want to scale, then you will eventually need to consider threading of some kind, whether it be the poor man's kind that Python and Node use, spawning multiple processes, or the good kind, fibers that automatically multiplex onto OS threads, as the Go and Haskell runtimes implement. Even the async poster-boy, nginx, does this via its workers.