- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Sat, 21 May 2022 20:00:04 +0000
- To: public-webrtc-logs@w3.org
> > Asynchronous API's come at a cost to web developers, as they turn JavaScript into a pre-emptive language. > > How so? @yoavweiss Everywhere a web developer has written `await` they're preempted, which means all their state assumptions made right before need to be reevaluated. This is a concrete cost to web developers, and can be a source of hard-to-diagnose races and bugs. Additionally, once a function or method is made asynchronous, everything that calls it is forced into being asynchronous as well, so the problem spreads like wildfire. The article I linked to explains this problem in some detail with examples, so I'm not sure what's unclear. Hope this helps. If not, I trust sure there are Google colleagues that can explain this better than I can. > > I recommend [Why coroutines won’t work on the web](http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/) as required reading here. > > Reading through this, I'm failing to understand the relevance. Are you suggesting that Promises are the equivalent of co-routines? No, the article was written in 2011 when Promises existed, but `async`/`await` didn't. At the time there was pressure from web developers to solve what that ultimately ended up solving a few years later. But how to do it wasn't yet clear. ### Ever questioned why the `await` keyword is needed, or why only `async` functions can use it? This is that article. A the time it wasn't clear why those restrictions were needed. But take away either of those requirements, and _then_ you have "co-routines" (the author's term for every function you call being able to preempt you in a single-threaded environment). The gem of the article (besides describing the preemption problem and why JS doesn't need locks), was recognizing that [generators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*) didn't have this problem, because the `yield` keyword was explicit. This meant JS developers could tell where preemption would happen and where it couldn't, so they could take appropriate steps. As you may know, `async`/`await` in JS ended up being [built on](https://stackoverflow.com/questions/36196608/difference-between-async-await-and-es6-yield-with-generators) generators. The misguided _make-everything-async-there's-no-downside_ crowd don't seem to understand this or care, that the logical end of what they're advocating (`await` everything!¹) quickly degrades JS into this pre-emptive (co-routine) language again. I'm sure they would try to invent locks in JS to solve it. Thankfully, these views are more rare these days than they were in 2011, which is why I had to go back that far for sourcing. --- <sub>1. I'm contrasting extremes to aid explanation here. Clearly one more async method isn't the problem, nor does the problem doesn't only arise at the extreme. But my aim here was to clarify why the design rules we have matter, and mustn't be violated except for reasons we can all agree are sufficient.</sub> -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1133760626 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 21 May 2022 20:00:06 UTC