4 ms·

> One of the fundamental problems is that many UI applications on Windows, Linux, and macOS call functions that are not specified to run in a bounded amount of

> One of the fundamental problems is that many UI applications on Windows, Linux, and macOS call functions that are not specified to run in a bounded amount of time. Here’s a basic example: many applications don’t think twice about doing file IO in a UI event handler. That results in a tolerable amount of latency most of the time on standard disk drives but what if the file is stored on a network drive? It could take much longer than a second to service the file request. This will result in a temporarily hung application with the user not knowing what is happening. The network drive is operating correctly, the UI application isn’t. Say what you will about JavaScript, but a great thing it's done for modern software is making async programming default and ergonomic. With most APIs, you couldn't block on IO if you tried. Which means web UIs never do

taeric 3y ago
Huh? It used to be very common to find that a web page was stuck processing some script. Still isn't that uncommon, all told. You are mostly right that you couldn't block on IO, necessarily, but you could still hose up the event thread quite heavily.
- 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 ago
    All you need to is `await` an IO operation on the UI thread.
    - taeric 3y ago
      My 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 ago
      Not 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 ago
        Not on await, no, unless the caller/awaiter is async too?
        brundolf 3y ago
        The 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 ago
        I'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 ago
        Every 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 ago

Huh? It used to be very common to find that a web page was stuck processing some script. Still isn't that uncommon, all told. You are mostly right that you couldn't block on IO, necessarily, but you could still hose up the event thread quite heavily.

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 ago
  All you need to is `await` an IO operation on the UI thread.
  - taeric 3y ago
    My 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 ago
    Not 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 ago
      Not on await, no, unless the caller/awaiter is async too?
      - brundolf 3y ago
        The 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 ago
        I'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 ago
        Every 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)