> Another thing we forget is that web browsers are on an entirely different level than other GUI applications because a web browser is designed to stay responsi

> Another thing we forget is that web browsers are on an entirely different level than other GUI applications because a web browser is designed to stay responsive to the user when loading multiple streams of data over a slow network. Contrast that to desktop applications where the "beachball" or whited-out windows is normal and unavoidable. Agreed that beginners using desktop GUI toolkits often make the mistake of putting long-running code in a button press callback, and then the GUI freezes. But it's pretty easy to avoid this, so long as you know about it. If you're doing network/IO related stuff, make your callback async and await the data. GUI toolkits often have an event loop built in that can run user-supplied async code. If you're doing CPU intensive work, spawn a thread (maybe in a threadpool), and send data back to the GUI thread over a channel (the GUI thread uses async callbacks to check the channel). Not as easy as async, but often GUI toolkits encapsulate this into some kind of "Task" object for you that can take out some of the boilerplate.