asynchronous

posts displayed by tag

Parallel
JavaScript

Concurrency in JavaScript

Just like with Flash, JavaScript code runs by default on the UI thread, and any expensive computation will usually affect the UI responsiveness. As you may know, at 60 fps, you have around 16ms (1000ms/60) per frame to do what you have to do (computations, rendering and other misc logic). If you exceed that budget, you will alter the frame rate and potentially make your content feel sluggish or worse, unresponsive.

Frame budget

Frame budget

Web Workers are now broadly available in most browsers even on mobile (caniuse.com stats for Web Workers) and give you the power of concurrency from within JavaScript. It will allow you to move expensive computations to other threads, to permit best responsive programming, and ideally open the doors in the future┬áto true parallelization in JavaScript. Let’s have a look at the reasons why you may be interested into leveraging Web Workers.

  • Responsive programming: When you have an expensive computation and don’t want to block the UI.
  • Parallel programming: When you want to leverage multiple CPU cores by having computations running concurrently to solve a specific task.

We will see later on that parallel programming with Web Workers can be challenging, and that they are not really designed for that today unfortunately. But before we dive into the details of responsive programming and parallel programming, let’s start with some more details about Web Workers. Note that we will cover here dedicated Web Workers, not the shared Web Workers.

Posted on July 1, 2013 by Thibault Imbert · 24 comments Read More