近期答案(2018)

你可以使用Greenlet:

移动一个异步函数到它自己的线程中。Workerize的简化单功能版本。

例子:

import greenlet from 'greenlet'

const getName = greenlet(async username => {
  const url = `https://api.github.com/users/${username}`
  const res = await fetch(url)
  const profile = await res.json()
  return profile.name
})

console.log(await getName('developit'))

控制台:

var worker=new Worker(window.URL.createObjectURL(new Blob([function(){
  //Long-running work here
  postMessage('done');
}.toString().split('\n').slice(1,-1).join('\n')],{type:'text/javascript'})));

worker.addEventListener('message',function(event){
  console.log(event.data);
});

html5rocks在HTML中嵌入web worker代码的解决方案相当糟糕。 而一团转义的JavaScript-as-a-string也不会更好，尤其是因为它使工作流程复杂化(闭包编译器不能操作字符串)。

我个人非常喜欢toString方法，但是@dan-man THAT正则表达式!

我喜欢的方法是:

// Build a worker from an anonymous function body
var blobURL = URL.createObjectURL( new Blob([ '(',

function(){
    //Long-running work here
}.toString(),

')()' ], { type: 'application/javascript' } ) ),

worker = new Worker( blobURL );

// Won't be needing this anymore
URL.revokeObjectURL( blobURL );

支持是这三个表的交集:

http://caniuse.com/#feat=webworkers http://caniuse.com/#feat=blobbuilder http://caniuse.com/#feat=bloburls

然而，这对SharedWorker不起作用，因为URL必须是精确匹配的，即使可选的'name'参数匹配。对于SharedWorker，您需要一个单独的JavaScript文件。

2015年更新——ServiceWorker奇点到来

现在有一种更有效的方法来解决这个问题。 同样，将工作代码存储为函数(而不是静态字符串)，并使用. tostring()进行转换，然后将代码插入CacheStorage中您选择的静态URL下。

// 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 exposed
caches.open( 'myCache' ).then( function( cache )
{
 cache.put( '/my_workers/worker1.js',
  new Response( workerScript, { headers: {'content-type':'application/javascript'}})
 );
});

有两种可能的退路。ObjectURL和上面一样，或者更无缝地将一个真正的JavaScript文件放在/my_workers/worker1.js

这种方法的优点是:

还可以支持SharedWorkers。 选项卡可以在固定地址共享单个缓存副本。blob方法为每个选项卡增加随机objecturl。

网络工作者在完全独立的上下文中操作，就像单个程序一样。

这意味着代码不能以对象的形式从一个上下文中移动到另一个上下文中，因为它们可以通过属于另一个上下文中的闭包引用对象。 这一点尤其重要，因为ECMAScript被设计成一种单线程语言，并且由于web worker在单独的线程中操作，那么您将有执行非线程安全操作的风险。

这再次意味着web工作者需要用源代码形式的代码进行初始化。

WHATWG的规格说明说

如果原点的结果 绝对URL是不一样的 输入脚本的起源，然后抛出 SECURITY_ERR异常。 因此，脚本必须是外部文件 和原来一样的方案 页面:您无法从 data: URL或javascript: URL，和一个 页面无法启动工作 使用http: url脚本。

但不幸的是，它并没有真正解释为什么不允许将带有源代码的字符串传递给构造函数。

我认为更好的方法是使用Blob对象，下面你可以看到一个简单的例子。

// create a Blob object with a worker code
var blob = new Blob(["onmessage = function(e) { postMessage('msg from worker'); }"]);

// Obtain a blob URL reference to our worker 'file'.
var blobURL = window.URL.createObjectURL(blob);

// create a Worker
var worker = new Worker(blobURL);
worker.onmessage = function(e) {
  console.log(e.data);
};
worker.postMessage("Send some Data"); 

您可以创建一个JavaScript文件，该文件可以感知其执行上下文，并且可以充当父脚本和工作脚本。让我们从这样一个文件的基本结构开始:

(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);

如您所见，脚本包含父进程和工作者进程的所有代码，检查它自己的实例是否是一个具有!document的工作者进程。有点笨拙的script_path计算用于精确计算相对于父页的脚本路径，因为提供给新Worker的路径是相对于父页的，而不是相对于脚本的。