Web workers without a separate Javascript file?
http://www.html5rocks.com/en/tutorials/workers/basics/#toc-inlineworkers
What if you want to create your worker script on the fly, or create a self-contained page without having to create separate worker files? With Blob(), you can "inline" your worker in the same HTML file as your main logic by creating a URL handle to the worker code as a string
Full example of BLOB inline worker:
<!DOCTYPE html><script id="worker1" type="javascript/worker"> // This script won't be parsed by JS engines because its type is javascript/worker. self.onmessage = function(e) { self.postMessage('msg from worker'); }; // Rest of your worker code goes here.</script><script> var blob = new Blob([ document.querySelector('#worker1').textContent ], { type: "text/javascript" }) // Note: window.webkitURL.createObjectURL() in Chrome 10+. var worker = new Worker(window.URL.createObjectURL(blob)); worker.onmessage = function(e) { console.log("Received: " + e.data); } worker.postMessage("hello"); // Start the worker.</script>
The html5rocks solution of embedding the web worker code in HTML is fairly horrible.
And a blob of escaped JavaScript-as-a-string is no better, not least because it complicates work-flow (Closure compiler can't operate on strings).
Personally I really like the toString methods, but @dan-man THAT regex!
My preferred approach:
// Build a worker from an anonymous function bodyvar blobURL = URL.createObjectURL( new Blob([ '(',function(){ //Long-running work here}.toString(),')()' ], { type: 'application/javascript' } ) ),worker = new Worker( blobURL );// Won't be needing this anymoreURL.revokeObjectURL( blobURL );Support is the intersection of these three tables:
- http://caniuse.com/#feat=webworkers
- http://caniuse.com/#feat=blobbuilder
- http://caniuse.com/#feat=bloburls
This won't work for a SharedWorker however, because the URL must be an exact match, even if the optional 'name' parameter matches. For a SharedWorker, you'll need a separate JavaScript file.
2015 update - The ServiceWorker singularity arrives
Now there's an even more powerful way of solving this problem.Again, store the worker code as a function, (rather than a static string) and convert using .toString(), then insert the code into CacheStorage under a static URL of your choice.
// Post code from window to ServiceWorker...navigator.serviceWorker.controller.postMessage( [ '/my_workers/worker1.js', '(' + workerFunction1.toString() + ')()' ]);// Insert via ServiceWorker.onmessage. Or directly once window.caches is exposedcaches.open( 'myCache' ).then( function( cache ){ cache.put( '/my_workers/worker1.js', new Response( workerScript, { headers: {'content-type':'application/javascript'}}) );});There are two possible fall-backs. ObjectURL as above, or more seamlessly, put a real JavaScript file at /my_workers/worker1.js
Advantages of this approach are:
- SharedWorkers can also be supported.
- Tabs can share a single cached copy at a fixed address. The blob approach proliferates random objectURLs for every tab.
You can create a single JavaScript file that is aware of its execution context and can act as both a parent script and a worker. Let's start off with a basic structure for a file like this:
(function(global) { var is_worker = !this.document; var script_path = is_worker ? null : (function() { // append random number and time to ID var id = (Math.random()+''+(+new Date)).substring(2); document.write('<script id="wts' + id + '"></script>'); return document.getElementById('wts' + id). previousSibling.src; })(); function msg_parent(e) { // event handler for parent -> worker messages } function msg_worker(e) { // event handler for worker -> parent messages } function new_worker() { var w = new Worker(script_path); w.addEventListener('message', msg_worker, false); return w; } if (is_worker) global.addEventListener('message', msg_parent, false); // put the rest of your library here // to spawn a worker, use new_worker()})(this);As you can see, the script contains all code for both the parent's and the worker's point of view, checking if its own individual instance is a worker with !document. The somewhat unwieldy script_path computation is used to accurately calculate the script's path relative to the parent page, as the path supplied to new Worker is relative to the parent page, not the script.