[wongarsu]

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]

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.

[wongarsu]

What I was thinking about is that you do need a way to lock the UI when running multiple statements that update the UI. Something like a lockUI{} block (conceptually a critical section holding a lock on UI updates). This would for example allow you to prevent a situation where you have to change two data attributes on a button and the user clicks the bottom between those two updates. It would be on the programmer to keep those lockUI{} sections as short as possible.

If JavaScript 1.0 had included such a primitive you could run all other JavaScript in the background. Alas, the JavaScript we have is essentially putting all code into such an lockUI block, and this assumption is baked in to a lot of code

[pavlov]

If that language feature had been included, the early web would have been filled with tutorials that say: “Don’t forget to wrap all your code in lockUI{} because that guarantees it runs correctly and things don’t suddenly change behind your back!”

And then we’d have the popular web frameworks just taking the lock and running all user code inside it, and everything would be the same as today.

[greggyb]

But we’d have options. ~There aren’t any today.~

Ninja edit: there haven’t been any until workers.