Javascript 101: Web workers
Javascript is a single-threaded language which means it can only act on one task at a time. To handle multitasking Javascript switches between tasks just like a single-core machine would do via a concept known as concurrency — virtual parallelism.
This model though safe for non-blocking tasks can become a nightmare for heavy resource-demanding programs(e.g audio compression and sound conversion on the client) that most times need to run at the same time(parallelism) and not just have overlapping time periods(concurrency) with the main application. This is where Web workers come in.
What is a Web Worker?
A Web Worker is a feature of the browser (aka host environment) that provides multiple instances of the Javascript engine, allowing us to run different program in separate threads.
A web worker can be initialized as shown above and the browser will spin up a separate thread and let the worker file run as an independent program. This type of parallelism is called “task parallelism,” as the emphasis is on splitting up chunks of your program to run in parallel.
Note — JavaScript still doesn’t support multi-threaded execution. But through browsers, web workers affords us the ability to.
Worker Environments
The Worker does not have access to the page’s DOM but has a copy of the navigator, location, JSON, and applicationCache variables and can perform network operations (Ajax, Websockets) and set timer actions.
The w1 Worker object is an event listener and trigger, which lets you subscribe to events sent by the Worker as well as send events to the Worker as shown above;
Meanwhile, in the worker file above, we listen for the message event and access the transmitted payload from the data property of the event argument. A combination of all the snippets we’ve seen will create a dedicated worker file that would output “completed serious computation” after 5000 milliseconds at which time the main application can carry out other activities without its single thread being blocked.
This example of web workers although not practical enough paints an image of how other heavier processes are best handled on the browser like; Processing intensive math calculations, Sorting large data sets, Data operations (compression, audio analysis, image pixel manipulations, etc.)
Shared Workers
Having a worker dedicated to the main application kind of gets clunky as the need for shared resources grows across browser tabs. And the thought of having them recreated for each browser instance of the same app seems redundant. That's where Shared workers come in.
A shared worker is a kind of worker that can be accessed from several browsing context: windows, iframes or other workers
Because a shared Worker can be connected to or from more than one program instance or page on your site, the Worker needs a way to know which program a message comes from. This unique identification is called a “port” — think network socket ports. So the calling program must use the port object of the Worker for communication.
Inside the shared Worker, an extra event must be handled: “connect”. This event provides the port object for that particular connection. Other than these few nuances Shared and dedicated workers practically have the same implementation.
Conclusion
Web workers are an exciting technology which if used properly can give a sense of multi-threading in javascript in the browser. Its flexibility outside of the web page opens the door to features (Push notification, background sync, etc) that can be performed as a service and most times don’t need user interaction.
Next stop — Events
