大家好，我是Kason。前端工程师已经习惯在浏览器环境下单线程开发很多年了。随着浏览器广泛支持webworker，前端项目的复杂度逐渐增加，“使用工作线程来缓解主线程的计算压力”逐渐成为一种可行的方案。例如，React尝试在工作线程上执行运行时差异算法。但是，社区中很多第三方库或多或少都对DOM进行了操作，工作线程不能操作DOM的局限性（或特性）极大地限制了它的应用领域。partytown是一个只有6kb大小的库。它的作用是让工作线程拥有包括“操纵DOM”在内的多种能力。潘多拉魔盒一旦打开，这会不会成为前端多线程编程的起点？第三方库的劣势我们经常在Github上搜索第三方库，这些开源库大大提高了我们的开发效率。但是，第三方库存在很多潜在的隐患：第三方库可能会进行未知操作（比如向未知服务器发送请求），可能会过多占用主线程的计算能力，可能会使用一些有害的API（例如document.write），对于前端应用来说，无论是通过对于主线程的API，例如：window、document、localStorage、partytown劫持并通过代理将调用转发给它们。例如下面的代码：varw=document.body.clientWidth；涉及3个getter：getdocumentgetbodygetclientWidthpartytown将完成：劫持getter，转发给主线程获取数据，并返回步骤1和2之间的数据序列由于代理了主线程API，可以实现沙箱功能，如：限制访问document.cookie并返回自定义的navigator.userAgent禁止第三方库访问localStorage重置危险方法（如document.write）阻止脚步访问其他脚本对于网络请求，webworker会发送一个同步XHR请求，被ServiceWorker拦截后会异步与主线程通信。数据返回后，ServiceWorker响应WebWorker的请求。因此，从工作线程的角度来看，所有的调用都是同步的。这使得大多数本机API在工作线程和主线程中的行为相同。这意味着理论上任何第三方库都可以通过partytown迁移到工作线程。总结当然，凡事都需要权衡取舍。对于partytown：worker线程的DOM操作是阻塞的，效率不如主线程。ServiceWorker拦截到的请求与Network面板中的正常请求略有不同，类似于event.preventDefault()，Passive事件监听器对worker线程没有影响。不过，这毕竟是一个有意义的实验。相信在不久的将来，会有越来越多的前端应用受益于“多线程”。
