Never having uncommitted changes

The other day I was commenting on how quickly a collegue seems to be able to create a new PR for a change. For me I need to

1. stash my working branch's uncommitted changes, 
2. switch to main, 
3. pull down new changes,
4. make the new branch, 
5. make the actual change, 
6. commit the change,
7. push the branch, 
8. open PR,
9. switch back to my working branch, and 
10. un-stash the uncommitted changes. 

He said, in effect, "I never have uncommitted changes." He also mentioned heavy reuse of his command line history, and I know of his highly customized git config [*]. But it was the idea of never having uncommitted changes that struck me. I think I have finally figured out that I should always be making small, tactical commits rather than waiting for a semantic commit. Then, when ready for the PR, use rebase not just for small reorganizations, but for wholesale reorganization into semantic commits.

* My use of IntelliJ for most git operations precludes these efficiencies.

Background tasks

I don't like waiting on the completion of a task that should be run in the background. For example, when I bookmark a page using a Delicious bookmarklet it presents a modal dialog box that has me wait for the bookmark to be made on Delicious' servers. The saving might only take a short time but the length of this short time varies greatly. The unknown wait is a serious obstacle to maintaining flow.

What I would like to see is for web browsers to have a background tasks API and user interface. A task is a JavaScript function. A web page or application (webapp) can add a task to the list of background tasks. The execution of the background task has the same constraints as any other task running in a give webapp from a specific web site.

The task is run by the browser when it has the chance. There are no guarantee of timeliness; just a promise of best effort. For simplicity, all the tasks in the list are run in the order added by the adding webapp. That is, if pages A and B both add 5 tasks to the background list then the tasks will be run in the order A1, B1, A2, B2, A3, B3, A4, B4, A5, B5. All tasks "succeed" in that any errors that occur must be conveyed to the originating webapp and its existing enqueued tasks. For example, a status of the task is kept in a cookie and the webapp & its tasks look at this cookie to determine the right course of action. The only indication to the user of tasks status will be a message in the task history. The user must not be expected to "respond" to the status message. The webapp is allowed to enumerate its tasks and to cancel them.