Hi Siniy-Kit,
As others have pointed out, the fundamental problem here is that long running JavaScript tasks that block the main thread cannot update the DOM while they are processing. DOM updates are deferred until the thread completes.
I'm interested in fixing it by building a new "workflow" mechanism that supports long running tasks with a user interface, giving them progress bars and cancel buttons.
A workflow basically means executing an action tiddler (the action widgets in a particular tiddler), waiting for the next tick, and then following some simple rules to determine the next action tiddler to be executed. The refresh process would operate as usual in between the execution of action tiddlers, so the user interface would update in the usual way.
As discussed elsewhere, the behaviour of sequential action widgets can be highly confusing. This is due to the fact that the widgets are parsed and rendered in one go before they are executed, "freezing" the values of attributes to the value they had before execution started. The workflow mechanism wouldn't change that, but it would mitigate it because there would be no such subtlety to the execution of sequential workflow steps. We'd perhaps get to the point where action widgets themselves would be hidden from the vast majority of users; most end user actions could be accomplished through stitching together existing workflow steps, rather than users having to write action widgets directly.
With any luck, we should be able to make an editable visual representation of the workflow, something like the below screenshot from the Shortcuts app on the iPad. We should also be able to make a basic debugger that highlights steps as they are executed.
Workflows would be particularly useful with integrated support for APIs, so that we could for example write workflows to use a remote service to compress images, to save individual tiddlers to GitHub, or to scrape web data.
Best wishes
Jeremy