| > Callbacks, promises, generators are all there to essentially make async code sync I think they actually do quite the opposite: they keep async code async. JavaScript doesn't really have a (non-terrible) way to make async code sync. Note that I'm assuming that by "being able to use return values of my methods without sweating," you mean "get the thing I want out of the return type somehow." Or, in other words, things like getting a value out of a Future. The problem with that approach is that it blocks the calling thread, so what happens if you have 50 connections? Or 200? Or 10,000? The same reason I like that JavaScript and JavaScript libraries try very hard to keep things asynchronous is the same reason highly concurrent software tends to be event based rather than thread based: it's simply more efficient. I think it can be a challenge to keep mental track of state in JavaScript due to the nature of async stuff, but it can also be liberating in a way once you figure out the right way to pack away your state for whatever problem your working on. It makes it easy to break things into small components and reason about pieces instead of the whole while maintaining decent efficiency compared to having tons of threads around. There's also of course the incredible niceness of JavaScript being single threaded in that typical multithreading concerns are not a problem. If you want to update a variable in some callback, you just do it. You don't have to worry about locking or atomicity, etc. I can't tell you how many times I've ended up with a mess of Java code in which I'm not actually sure if it's correct or not. That's likely my fault, but still something I enjoy getting to not think about when doing JS. In short, I suppose it just comes down to different preferences. I often find myself working on concurrency in Java and wishing that it were more like JavaScript :). Interesting, the JavaScript approach can be pretty easily recreated in Java (and sometimes a very useful tool), but the Java approach is much harder to do in JS, at least with Node. |
Big threaded reactor style designs can be, but those aren't exactly event driven.
Small events generally are the opposite of performance, increasing concurrency and synchronisation dependencies between threads.
If you meant responsiveness or latency, maybe you have a point, but current UI frameworks have been event driven since about forever.