190

I am looking for real-world scenarious for using Web Workers API.

Sergey Ilinsky
  • 31,255
  • 9
  • 54
  • 56

3 Answers3

157

  • John Resig (of jQuery fame) has a bunch of interesting examples of using web workers here (mirror) - games, graphics, crypto.

  • Another use is Web I/O - in other words, polling URLs in background. That way you don't block the UI waiting for polling results.

  • Another practical use: in Bespin, they’re using Web Workers to do the syntax highlighting, which you wouldn’t want to block your code editing whilst you’re using the app.

  • From Mozilla: One way workers are useful is to allow your code to perform processor-intensive calculations without blocking the user interface thread.

As a practical example, think of an app which has a large table of #s (this is real world, BTW - taken from an app I programmed ~2 years ago). You can change one # in a table via input field and a bunch of other numbers in different columns get re-computed in a fairly intensive process.

The old workflow was: Change the #. Go get coffee while JavaScript crunches through changes to other numbers and the web page is unresponsive for 3 minutes - after I optimized it to hell and back. Get Back with coffee. Change a second #. Repeat many times. Click SAVE button.

The new workflow with the workers could be: Change the #. Get a status message that something is being recomputed but you can change other #s. Change more #s. When done changing, wait till status changes to "all calculations complete, you can now review the final #s and save".

d9k
  • 1,476
  • 3
  • 15
  • 28
DVK
  • 126,886
  • 32
  • 213
  • 327
  • 5
    Great links! I had never heard of Workers ... mmm, Workers. (Time to go take a long, hot shower ...) – Peter Rowell Jul 10 '10 at 00:59
  • 68
    I know this is a two-year-old answer, but I just wanted to mention that you shouldn't need Web Workers for item #2 (polling URLs). XHR happens asynchronously and doesn't block; there's no need to run XHR requests on a separate thread. (Of course, in a modern app you'd want to use WebSockets instead of polling.) – josh3736 May 01 '12 at 04:03
  • 6
    @josh3736 - You are correct but I'm now curious as to whether doing many parallel XHR aync requests can somehow make the browser unhappy? Also, you need local resources to process XHR responses where the workers might be useful. – DVK Aug 13 '12 at 10:39
  • If all of the parallel requests are to the same server, you'll hit the per-hostname [limit somewhere between 2 and 9](http://www.browserscope.org/?category=network) concurrent connections. (I'd assume that the limit applies across *all* connections, whether initiated from the main thread or a worker.) Of course, if you have 10 concurrent requests running at one time, you probably need to rethink your application's design. – josh3736 Aug 13 '12 at 14:07
  • @josh3736, I know this is now an even older answer than your comment earlier-- but here's some food for thought: sometimes it's less about performance benefits and more about "reasoning" an application. Sending XHR off to a web worker can result in cleaner and easier to reason code; and since the messaging can either be used as a publish analogy or it can publish an actual event, it makes future change-outs to websockets a painless process for the front end. – Greg Pettit May 21 '16 at 05:31
  • 2
    Excuse my simple question, but what do you refer to as "#" in your example above? – shrewdbeans Mar 01 '17 at 07:34
  • @shrewdbeans like changing a numerical value in an excel spreadsheet that has other cells dependent on that value to calculate their own cell's value – c0de Jul 12 '20 at 22:19
41

I have used them for sending larger amounts of data from the browser to server. Obviously, you can do this with regular AJAX calls, but if this takes up one of the precious connections per hostname. Also, if the user does a page transition during this process (e.g clicks a link), your JavaScript objects from the previous page go away and you can't process callbacks. When a web worker is used, this activity happens out of band, so you have a better guarantee that it will complete.

Kevin Hakanson
  • 41,386
  • 23
  • 126
  • 155
  • 2
    But you have to exchange the message with the web-worker. When the cost of this operation deserves the benefit ? – Danielo515 Apr 17 '18 at 13:59
10

Another Use case:

Compressing/De-compressing files in the background, if you have a lot of images and other media files that are exchanged from the server in compressed format.

sbr
  • 4,735
  • 5
  • 43
  • 49
  • 49
    This shouldn't be happening in JavaScript. Images are *already* compressed (PNG, JPEG) using algorithms designed to efficiently compress image data. Throwing another layer of compression on top can actually *increase* the data's size. For other types of data (eg a large JSON file), compression should be handled by the browser using standard HTTP gzipping. **If you're doing compression in JavaScript, you're probably *doing it wrong*.** – josh3736 May 01 '12 at 03:59
  • 13
    I see some users disqualifying the use case, but here's what i meant to say. consider an application like MS word, like a powerful document editor through which you could embed images,music files, data, excel sheets etc all in ONE file. and consider that you have a web based client and a desktop client and a IOS/Android client. For this kind of a use case, you can store all the file contents in a zip file and then unzip at each client. – sbr Jan 29 '13 at 18:25
  • I hope the above comment makes sense. Please give your suggestions if you could think of smarter ways to achieve this. – sbr Jan 29 '13 at 18:26
  • 3
    The Instapaper bookmarklet compresses the page being saved before sending to it to the server. It saves time and bandwidth. – stevendaniels Oct 31 '13 at 03:51
  • 13
    @josh3736 The only thing a browser can do is gunzip a file from a web server (or browser cache). It can't decompress data from local storage, nor from a websocket, and it can't compress at all. Web apps are sending an ever increasing amount of data upstream, and compression for this is extremely useful. Equally valid a year ago when this was posted: **If you can't think of any valid use-cases for JavaScript compression, you probably lack imagination.** – Adria Dec 10 '13 at 09:27
  • 2
    @Adria: The websocket standard is in the process of [adding compression support](http://stackoverflow.com/a/19300336/201952). If you're dealing with images generated in the browser (``), you can get the image data in a compressed format (ie png). My point was not that it is *never* appropriate to compress in JS; my point was that *in most cases*, it is **not**, and for most cases -- *especially* dealing with images, which is what this answer talks about -- there is a better alternative to rolling your own compression. – josh3736 Dec 10 '13 at 15:43
  • @josh3736 PNG images can become huge with complex data. They can be tamed a bit with optipng/pngout, but those don't run in the browser. – Steven Vachon Sep 17 '14 at 22:17