4 ms·
If you're actually doing busy logic then it'll block the UI thread, but you have to work pretty hard to do that, and IO won't block the UI thread
by brundolf 3y ago
If you're actually doing busy logic then it'll block the UI thread, but you have to work pretty hard to do that, and IO won't block the UI thread
- TeMPOraL 3y agoAll you need to is `await` an IO operation on the UI thread.
- taeric 3y agoMy favorite is when someone builds a ton of filtering capability locally that loads all of the data and then filters it down. Was a common mistake many editors (such as emacs) used to make, so not at all blaming incompetence. But is absolutely a trap.
- brundolf 3y agoNot true. The await statement will kick the operation over to the event loop to wait for a response, and the thread itself will keep humming along (pulling other events off the loop, handling animations and scrolling, etc)
- TeMPOraL 3y agoNot on await, no, unless the caller/awaiter is async too?
- brundolf 3y agoThe function containing the `await` waits, but the thread does not; it switches to doing other things: - Page scrolling/rendering - If the user triggers an event, like clicking on a button, that JS event handler is independent from the waiting function and can run while it's waiting - Same thing if some other `await`ed IO resolves; that function can resume while the other one is still waiting This is why async/await exists. It allows our code to tell the runtime "let me know when this is ready, otherwise do whatever you want in the meantime". Many languages have a similar feature now, but in JavaScript it's especially fundamental to the language and ecosystem, which means code gets written this way by default, which means JS programs don't have the problem mentioned in the OP by default.
- taeric 3y agoI'm curious how this works with event handlers. Suppose you have one on a button that will fetch a number from a server and show it. For fun, assume the server is basically fizzbuzz, but with a 2 second delay for every multiple of 3/5 and a 1 second delay otherwise. If I click the button 4 times quickly (less than a second for all clicks), what happens? I'm assuming it is on the programmer to do some smart debouncing in the event handler?
- brundolf 3y agoEvery click will immediately fire a request, and they will come back in whatever order they come back in based on the server's timing (and network latency, and whatever else) Done the straightforward way, you will end up displaying whichever one took the longest to return. I've run into this class of bug before, and since then I make sure to design my primitives to guard against it (always assign the latest-requested instead of latest-received result into state)
- taeric 3y agoAwesome, thanks for confirming my thoughts there. Was hoping to prototype a test soon.
- TeMPOraL 3y agoOkay, I think I am confused about how this works in JS. I've written my fair share of event-driven code, but managed to avoid working with actual async/await. My understanding was that calling an async function does what you describe, but awaiting it literally blocks the caller thread - because what else could it block? Your description sounds like something I'd expect of a yield instruction.
- brundolf 3y agoIt blocks the logic flow of the current function, but in a way that can be resumed later If it helps you think about it, any await statement can be converted straightforwardly to an old-fashioned promise resolution with a callback: async function foo1() { doStuff() const res = await doIO() return 'Result: ' + res } function foo2() { doStuff() return doIO().then(res => { return 'Result: ' + res }) }