[angryteabag]

As a novice developer, coming from Java, I was taken aback by how forceful and messy JS's async programming style is (I started with node.js then moved to the browser).

Callbacks, promises, generators are all there to essentially make async code sync, which seems to make the code hard to follow, difficult to scale, modularise and debug.

I think JS took this approach because of the limitation of older browsers, which were unable to use threading, so as to not block IO they forced concurrency using queues requiring async style code.

We must have just stuck with it because it's just been around for long enough and it would be hard to get everyone to change.

it's 2016 and I like being able to use the return values of my methods without sweating. PLEASE, for the love of god, replace JS with something with the same cushy syntax but makes sense.

Then again, I could just be bad at programming and not know what I am talking about - I sincerely hope that is the case.

[douche]

This kind of hits one of the problems with JS on the head. There are too many different ways to do things, at all levels of abstraction, because it was such a limited, dumpster-fire of a language for so long, implemented in so many mutually incompatible ways by every different version of every browser, and so to do anything much more complicated than wiring up some basic callbacks on a page, you had to roll big chunks of infrastructure that better designed and more mature languages built in. So you end up with a half-dozen different patterns for object-oriented programming, another half dozen patterns for making async code less awful, three or four different patters for defining modules, etc, ad nauseum.

</rant>

[chug]

> 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.

[AstralStorm]

I have yet to see event based software that is more efficient than plain old sync code.

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.