Events are not a substitute for Threads, and Threads are really not as hard as people would like to claim when you're working at the level of an application developer.
Keep in mind that hundreds of thousands (wild guess) .NET developers have worked with both Threads and Events for years in WinForms and WebForms without much trouble. Because 99% of the time as long as you follow a few simple rules about what you're passing to an event, and you use built-in thread-safe collections along with the occasional custom double-lock, you're going to be safe. The framework takes care of most of it for you.
Disclaimer: Having little experience with Node.js and some of the other new-ish evented frameworks, the following observation is probably at least somewhat off-base. But it occurred to me the other day that in a lot of ways many OSS projects are trending towards popularizing a model Microsoft mainstreamed (at least in my limited decade-plus experience). ie: "Delegate All The Things!"
Wasn't really a fan of it then (there are definitely advantages, but I think you can make the claim it went entirely too far) and I guess that's what left a sour taste in my mouth when anyone brings up Evented programming as some sort of silver bullet.
In addition to that, considering my experience with Thread Pooling and Events, it always strikes me as odd when they're presented as competing solutions. They work best together IMO, as they're complementary techniques, not competing. If you need shared state, brokers and/or IPC are a poor substitute for the performance of Threads (IME). Plus they're much more complex if you have a robust set of Thread Safe libraries to draw on.
