top | item 42593915

(no title)

gttalbot | 1 year ago

What's old is new again. Some of the same techniques used to keep pre-MacOS-X applications responsive, back when MacOS was cooperatively scheduled, show up here.

This begs the question of what is a reasonable programming model? In the MacOS case, the forcing function was buying NeXT, using their Unix kernel for MacOS, and literally firing the OS engineers who disagreed with preemptive multitasking.

For these browsers, is there a programming model that could be instituted where processing in these handlers didn't hold up the main UI thread?

discuss

order

wongarsu|1 year ago

The previous decade certainly feels like a big resurgence of cooperative multitasking, in the rise of JavaScript and the rise of async in all languages.

Making JavaScript (conceptually) runs in the UI thread was imho one of the mistakes owed to the extremely simple early versions of JavaScript. We would be better off if JavaScript was preemptively scheduled (whether by the browser or by the OS) with language primitives to lock the UI in specific execution sections.

ciconia|1 year ago

Locking the UI while doing a lengthy operation is hardly an acceptable solution. A better solution would be to indicate to the user an async operation is in progress, and optionally provide a button for canceling the operation.