webworkers
Download as PPTX, PDF•1 like•994 views
Web workers allow JavaScript to run concurrently in the background without blocking the UI. They allow computationally intensive tasks to be offloaded to separate threads. There are two types: dedicated workers run in a separate file while shared workers can be accessed by multiple scripts. Workers communicate with the main thread asynchronously through messages and run independently with some limitations like no direct DOM access. They improve performance for intensive tasks like processing large data or polling web services in the background.
![Transferrable objects
◦ Data is transferred from one context to another.
◦ Like pass-by-reference but calling context is no longer available once transferred to the new
context.
worker.postMessage(arrayBuffer, [arrayBuffer]);
window.postMessage(arrayBuffer, targetOrigin, [arrayBuffer]);](https://image.slidesharecdn.com/45c9cf53-6231-4201-bb2e-9940348fe825-161126073752/85/webworkers-19-320.jpg)
![Limitations of Web Workers
RESTRICTED LOCAL ACCESS
◦ Web Workers will not work if the web page is being served directly from the filesystem (using
file://)
◦ But can overcome using,
◦ local development server such as XAMPP
◦ Using Inline Workers with blob URLs.
var blob = new Blob([
"onmessage = function(e) { postMessage('msg from worker'); }"]);
var blobURL = window.URL.createObjectURL(blob);
var worker = new Worker(blobURL);](https://image.slidesharecdn.com/45c9cf53-6231-4201-bb2e-9940348fe825-161126073752/85/webworkers-23-320.jpg)
webworkers
- 2. The Problem: JavaScript Concurrency
- 3. The Problem: JavaScript Concurrency ◦ Compatibility ◦ Static typing ◦ Accessibility ◦ Performance ◦ JavaScript is a single-threaded environment. ◦ multiple scripts cannot run at the same time.
- 4. The Problem: JavaScript Concurrency Developers mimic 'concurrency' by using techniques. ◦ setTimeout() ◦ setInterval() ◦ XMLHttpRequest ◦ event handlers.
- 5. Introducing HTML5 Web Workers
- 6. Web Workers The Web Workers specification defines an API for running scripts in the background independently of any user interface scripts. Web Workers allow you to do things like fire up long-running scripts to handle computationally intensive tasks, but without blocking the UI or other scripts to handle user interactions.
- 7. Types of Web Workers There are two kinds of workers, ◦ Dedicated Workers. ◦ Shared Workers.
- 8. Dedicated Workers ◦ The code must be contained in a separate file. ◦ Communication via message passing. ◦ Event listeners to catch messages between source and worker.
- 9. Dedicated Workers Step 1 - Create a new Worker object in your main page. var worker = new Worker('task.js');
- 10. Dedicated Workers Step 2 - Communicating with a Worker via Message Passing. Main script: The worker: worker.postMessage('Hello World'); worker.postMessage({'cmd': 'start', 'msg': 'Hi'}); self.postMessage('Hello Back');
- 11. Dedicated Workers Step 3 - Listen to message event. Main script: The worker: worker.addEventListener('message', function(e) { console.log('Worker said: ', e.data); }, false); self.addEventListener('message', function(e) { self.postMessage(e.data); }, false);
- 12. Dedicated Workers Step 4 - Stop a worker. Main script: The worker: worker.terminate(); self.close ();
- 13. Check Web Worker Support If (typeof(Worker) !== "undefined") { // Yes! Web worker support! } else { // Sorry! No Web Worker support.. }
- 14. Loading External Scripts importScripts('script1.js', 'script2.js');
- 15. Handling Errors ◦ When an error occurs while a worker is executing, onerror event handler is called. ◦ Receives an event named error. ◦ Message - A human-readable error ◦ Filename - The name of the script file in which the error occurred. ◦ lineno - The line number of the script file on which the error occurred.
- 17. Subworkers(Nested Workers) Workers have the ability to spawn child workers. limitations ◦ Subworkers must be hosted within the same origin as the parent page. ◦ URIs within subworkers are resolved relative to their parent worker's location rather than that of the owning page.
- 18. Communicating objects Can pass more complex types in/out of Workers. ◦ String, JSON object. ◦ File, Blob, ArrayBuffer(using structured cloning algorithm). Messages passed between the main page and workers are copied, not shared.
- 19. Transferrable objects ◦ Data is transferred from one context to another. ◦ Like pass-by-reference but calling context is no longer available once transferred to the new context. worker.postMessage(arrayBuffer, [arrayBuffer]); window.postMessage(arrayBuffer, targetOrigin, [arrayBuffer]);
- 20. Features Available to Workers ◦ The navigator object ◦ The location object (read-only) ◦ XMLHttpRequest ◦ setTimeout()/clearTimeout() andsetInterval()/clearInterval() ◦ The Application Cache
- 21. Limitations of Web Workers LIMITED ACCESS ◦ The DOM (it's not thread-safe) ◦ The window object ◦ The document object ◦ The parent object
- 22. Limitations of Web Workers SAME ORIGIN POLICY ◦ All of your worker scripts must be served from the same domain as the script that is attempting to create the worker. ◦ This also applies to the protocol. For example a https:// page cannot call on a worker served using http://.
- 23. Limitations of Web Workers RESTRICTED LOCAL ACCESS ◦ Web Workers will not work if the web page is being served directly from the filesystem (using file://) ◦ But can overcome using, ◦ local development server such as XAMPP ◦ Using Inline Workers with blob URLs. var blob = new Blob([ "onmessage = function(e) { postMessage('msg from worker'); }"]); var blobURL = window.URL.createObjectURL(blob); var worker = new Worker(blobURL);
- 24. Use Cases of Web Workers ◦ Prefetching and/or caching data for later use ◦ Code syntax highlighting or other real-time text formatting ◦ Spell checker ◦ Analyzing video or audio data ◦ Background I/O or polling of web services ◦ Processing large arrays or humungous JSON responses ◦ Image filtering in <canvas> ◦ Updating many rows of a local web database
- 25. Browser Support
- 26. Questions?
- 27. Thank You.
Editor's Notes
- #3: imagine a site that needs to handle UI events, query and process large amounts of API data, and manipulate the DOM. Pretty common, right? Unfortunately all of that can't be simultaneous due to limitations in browsers' JavaScript runtime
- #4: There are a number of bottlenecks preventing interesting applications from being ported (say, from server-heavy implementations) to client-side JavaScript. Some of these include browser compatibility, static typing, accessibility, and performance. Fortunately, the latter is quickly becoming a thing of the past as browser vendors rapidly improve the speed of their JavaScript engines.
- #5: all of these features run asynchronously, but non-blocking doesn't necessarily mean concurrency. Asynchronous events are processed after the current executing script has yielded.
- #6: Bring Threading to JavaScript
- #9: Web Workers run in an isolated thread. As a result, the code that they execute needs to be contained in a separate file. Once the Web Worker is spawned, communication between web worker and its parent page is done using message passing.
- #10: If the specified file exists, the browser will spawn a new worker thread, which is downloaded asynchronously. The worker will not begin until the file has completely downloaded and executed. If the path to your worker returns an 404, the worker will fail silently.
- #11: Messages passed between the main page and workers are copied, not shared. For example, in the next example the 'msg' property of the JSON message is accessible in both locations. It appears that the object is being passed directly to the worker even though it's running in a separate, dedicated space. In actuality, what is happening is that the object is being serialized as it's handed to the worker, and subsequently, de-serialized on the other end. The page and worker do not share the same instance, so the end result is that a duplicate is created on each pass. Most browsers implement this feature by automatically JSON encoding/decoding the value on either end.
- #16: When a runtime error occurs in worker, its onerror event handler is called. It receives an event named error which implements the ErrorEvent interface.
- #18: This is great for f. Before you go spawning a worker farm, be cautious about hogging too many of the user's system resources. One reason for this is that messages passed between main pages and workers are copied, not shared. urther breaking up large tasks at runtime
- #19: It appears that the object is being passed directly to the worker even though it's running in a separate, dedicated space. In actuality, what is happening is that the object is being serialized as it's handed to the worker, and subsequently, de-serialized on the other end. The page and worker do not share the same instance, so the end result is that a duplicate is created on each pass. Most browsers implement this feature by automatically JSON encoding/decoding the value on either end.
- #22: Due to the fact that your Web Workers run outside of the main application thread they do not have the same access to JavaScript features as your main application does.