After you think it is necessary to work asynchronously in a web worker and even think that a good idea in the synchronization API for a background thread seems to be a terrible trap.
The fact is that synchronization is a fake for waiting for I / O. Regardless of whether they are asynchronous or synchronized, internally they are one and the same process of asynchronous operation . The worker should do interesting CPU work while waiting for I / O.
Moreover, we may already have asynchronous code for the user interface thread. Reusing asynchronous code is better than coding async for the foreground and synchronization for the background.
The Async API can create multiple transactions using different capabilities and modes. These asynchronous transaction flows alternate. Unable to rotate transactions in the synchronization API.
The only advantage we get in the synchronization API is easy to use. But an asynchronous workflow using a perspective / deferred template is already well understood.
Perhaps a good synchronization API is the process of scanning the cursor (also for the user interface thread), since it does not involve serialization and probably does not require I / O. However, IDBCursor for the synchronization API and IDBCursorWithValue for the asynchronous API will be confused, although the use cases are different.
A truly great idea for the synchronization API is a terrible trap for developers writing a high-performance program.