Hacker News new | comments | show | ask | jobs | submit login

My team just got finished re-writing a frontend JS app that went all-in on events for handling almost everything to a more declarative React app with more explicit dependencies. It still has some event bindings with a central store of state to re-render components, but they are isolated to a single, manageable mechanism.

Event-Driven architecture sounds like somewhat of a panacea with no worries about hard-coded or circular dependencies, more de-coupling with no hard contracts, etc. but in practice it ends up being your worst debugging nightmare. I would much rather have a hard dependency fail fast and loudly than trigger an event that goes off into the ether silently.

With events, most stack traces, call stacks, and flame graphs become useless dead ends. Tracing the flow of the program becomes a game of grepping the entire codebase for copy-and-pasted event names, trying to figure out everywhere the event is used, called, forwarded on to another event, etc. You can attach loggers, but if you go all-in on events, you will eventually end up with so many event calls and handlers that it becomes hard to tell signal from noise.

IMHO, there are way too many downsides to use events at the application architecture level. They are certainly useful for many other things in real applications (as the author states and warns), but not the basic nuts and bolts of your architecture.

TL;DR: The author is quite correct about his 'spaghetti code' warning that can happen with events everywhere.




The problem with this is that you're attempting to do an event-driven app that has a network layer inbetween and a language that has very little safety sorrounding it.

Event driven architectures are appropriate for services. Just not a JS based website.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: