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.
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
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.
