Web Workers vs Promises

Question

In order to make a web app responsive you use asynchronous non-blocking requests. I can envision two ways of accomplishing this. One is to use deferreds/promises. The other is Web Workers. With Web Workers we end up introducing another process and we incur the overhead of having to marshal data back and forth. I was looking for some kind of performance metrics to help understand when to chose simple non-blocking callbacks over Web Workers.

Is there some way of formulating which to use without having to prototype both approaches? I see lots of tutorials online about Web Workers but I don't see many success/failure stories. All I know is I want a responsive app. I'm thinking to use a Web Worker as the interface to an in-memory data structure that may be anywhere from 0.5-15MB (essentially a DB) that the user can query and update.

As I understand javascript processing, it is possible to take a single long-running task and slice it up so that it periodically yields control allowing other tasks a slice of processing time. Would that be a sign to use Web Workers?

Solution

`Deferred/Promises and Web Workers address different needs:

• Deferred/promise are constructs to assign a reference to a result not yet available, and to organize code that runs once the result becomes available or a failure is returned.

• Web Workers perform actual work asynchronously (using operating system threads not processes - so they are relatively light weight).

In other words, JavaScript being single threaded, you cannot use deferred/promises to run code asynchronously — once the code runs that fulfills the promise, no other code will run (you may change the order of execution, e.g. using setTimeout(), but that does not make your web app more responsive per se). Still, you might somehow be able to create the illusion of an asynchronous query by e.g. iterating over an array of values by incrementing the index every few milliseconds (e.g. using setInterval), but that's hardly practical.

In order to perform work such as your query asynchronously and thus off load this work from your app's UI, you need something that actually works asynchronously. I see several options:

• use an IndexedDB which provides an asynchronous API,

• run your own in-memory data structure, and use web workers, as you indicated, to perform the actual query,

• use a server-side script engine such as NodeJS to run your code, then use client-side ajax to start the query (plus a promise to process the results),

• use a database accessible over HTTP (e.g. Redis, CouchDB), and from the client issue an asynchronous GET (i.e. ajax) to query the DB (plus a promise to process the results),

• develop a hybrid web app using e.g. Parse.

Which approach is the best in your case? Hard to tell without exact requirements, but here are the dimensions I would look at:

• Code complexity — if you already have code for your data structure, probably Web Workers are a good fit, otherwise IndexedDB looks more sensible.
• Performance — if you need consistent performance a server-side implementation or DB seems more appropriate
• Architecture/complexity — do you want all processing to be done client side or can you afford the effort (cost) to manage a server side implementation?

I found this book a useful read.

Comments

[NoWar]

Would you mind to provide a more concrete example scenarios of Promise/WebWrokers usage please? Something that we can associate with UI. Thank you!

[Ray Foss]

You forgot cost. Can you afford to run/rerun heavy reports on separate servers with queuing/functions architecture. One thorn is that low powered devices exist, like the iPad Pro 10.5 inch with only 2gb of ram. It's so bad, they kill big canvas' preemptively faster than anything else.

[miraculixx]

Thanks for pointing it out. For clarity added that can you afford the effort to manage a server side implementation alludes to the cost side of it