Q:

JavaScript and Multi-threading by browser for async operations?

I'm experimenting with laying out data in indexedDB object stores and using Promise.all to extract the data, build HTML, and add it to different sections of a tabbed display within a single-page web application.
If Promise.all is used to extract the data from different object stores or different key ranges of the same store and then build HTML fragments and insert them before resolving each individual promise, is the browser really performing these steps concurrently such that the process will complete quicker?
To be more specific, there is one promise for the extraction of data for each tab in the display.  If the transaction completes successfully then the data is passed to a function that builds and inserts the HTML and, when it returns, the promise resolves.  The promises for each tab are grouped in the Promise.all and, when that resolves, the program navigates to the first tab and displays it.
Is this really working on multiple things at the same time or is it just providing a timing method to show the first tab only after it is known that data and HTML for all tabs have been successfully gathered and built?  
Is it accurate that this is quicker than chaining the promises to run one after the other with then statements but not faster than just kicking off each promise individually and placing a then on the first tab's promise to display it?
I know JS is a single-thread language but the documentation for some of these methods reads that "in a separate thread..."; so, I don't quite understand if the browser is performing things at the same time or not.
Thank you.

A:

First off, let's just stipulate that there's no use of webWorker threads so we're just  talking about regular Javascript in a web page.
In that case, there's only ONE thread of Javascript running at any given time and the whole system is event driven (more on that later).
So, when running actual Javascript code things can only run one at a time.  But, as soon as you make a function call that has a native-code backed non-blocking, asynchronous implementation, then the Javascript calls out to the native code, the asynchronous operation is initiated and then it immediately returns control back to the Javascript interpreter so more Javascript can run.  In this manner, you can start multiple asynchronous operations at once that will proceed independent of the Javascript interpreter.
How much independent they are and how parallel they are depends upon the implementation of those asynchronous operations.  If they are all accessing the same database, there may or may not be some real parallelism between database operations available - it all depends upon the database implementation.
Now, let's assume you did start multiple database operations and you are tracking when they a re all done with Promise.all().  As each one finishes, it will insert an event in the JS event queue.  When the JS interpreter has nothing else to do, it will pull the next event from the event queue and run the callback associated with the completion of that asynchronous operation.  When using Promise.all(), that callback will (among other things), mark that single operation as done and store its result for later access.  When, all the operations you are tracking with Promise.all() have completed in this manner, then the promise that Promise.all() returns will resolve and you can get access to the array of results.
Now to your specific questions...

If Promise.all is used to extract the data from different object stores or different key ranges of the same store and then build HTML fragments and insert them before resolving each individual promise, is the browser really performing these steps concurrently such that the process will complete quicker?

If each asynchronous operation is capable of efficient running in parallel with others (at the native code level), then "yes" the total time to completion will be faster if the operations are run in parallel, than if they are sequenced.

Is this really working on multiple things at the same time or is it just providing a timing method to show the first tab only after it is known that data and HTML for all tabs have been successfully gathered and built?

That depends upon the specific asynchronous operations and if multiple of them can be run in parallel.  Usually, they can, but not always.

Is it accurate that this is quicker than chaining the promises to run one after the other with then statements but not faster than just kicking off each promise individually and placing a then on the first tab's promise to display it?

Usually, yes.

I know JS is a single-thread language but the documentation for some of these methods reads that "in a separate thread..."; so, I don't quite understand if the browser is performing things at the same time or not.

The browser runs your Javascript (the executing of actual Javascript instructions) as a single thread (ignoring webWorkers here) with no parallelism.  But, when you call an asynchronous operation, that operation has an implementation in native code and that native code behind it is free to use threads or other asynchronous, non-blocking OS APIs/tools to do its job.  That may allow parallelism between separate asynchronous calls, thus allowing multiple calls to proceed in parallel.
The IndexedDB interface contains many asynchronous interfaces which means it is event driven and must be running asynchronously with some native code behind it.  You would have to test a given implementation of that database in a given browser to see how well it parallelizes multiple requests in-flight at the same time.  Each browser implementation could have different characteristics.

