Ask HN: Disadvantages of event-driven web architecture?

[suvike]

There's been a lot of talk about even-driven web servers lately - nodejs and Tornado come to mind - but I've not seen much discussion about _why_ we should or shouldn't be using event-driven architectures for our sites.

What's the downside? Why shouldn't I be using an event-driven architecture for all of my sites?

[wmf]

Lots has been written about threads vs. events, although most of the debate concerns low-level software like Web servers, not Web apps. The supposed benefit of event-driven architecture is performance, but this may be reduced in the future by massive multi-core and Web apps already have such low performance that it's not clear that the benefit is worth it. Events can also reduce stack memory wastage (e.g. in Comet situations), although Go shows that memory-efficient threads are possible. Event-driven code is generally more verbose (due to "manual stack ripping"; closures reduce this problem) and requires extra discipline because you can't ever call anything that blocks (like reading from a file). The recent trend in Web apps seems to be productivity over performance, which would seem to favor threads (note: not processes).

[qhoxie]

The most basic area where the evented model performs poorly is the most obvious one given its architecture - slow transactions. Depending on the set up, the event loop could be completely blocked by a slow transaction, thus nullifying many of the benefits.