无论是作为博客文章的主题,还是在演示文稿中提及, Web Workers都是我不时反对的一项技术。
在我最近参加的一次演讲中,演讲者谈到了网络工作者:
我不太确定为什么没有更多地使用它们。
考虑到这一点,我意识到,对于具有如此明显优势和 用例的技术,网络工作者的采用似乎相当缓慢或狭窄。
Web 工作者是否存在一些固有问题,使它们变得不那么有用?我只是在错误的地方寻找它们的使用示例吗?还是一般的 Javascript 程序员并不特别习惯于创建多线程应用程序。
无论是作为博客文章的主题,还是在演示文稿中提及, Web Workers都是我不时反对的一项技术。
在我最近参加的一次演讲中,演讲者谈到了网络工作者:
我不太确定为什么没有更多地使用它们。
考虑到这一点,我意识到,对于具有如此明显优势和 用例的技术,网络工作者的采用似乎相当缓慢或狭窄。
Web 工作者是否存在一些固有问题,使它们变得不那么有用?我只是在错误的地方寻找它们的使用示例吗?还是一般的 Javascript 程序员并不特别习惯于创建多线程应用程序。
它们没有被大量使用的主要原因(在我看来):
惯性。它们是一种相对较新的技术,人们还没有花时间学习它们。你参加了一次谈话,这意味着你走在了潮流的前面;那里有很多人甚至还没有听说过“网络工作者”这个词,更不用说考虑编写它们了。
浏览器兼容性。较旧的浏览器不支持它们。大多数人仍然需要为他们的网站至少支持 IE8,所以还不能使用这样的技术。
何必?使用新技术的唯一原因是它能否解决问题或取得新成果。大多数网站对网络工作者没有任何实际需求。或者即使他们这样做,他们也没有看到需要。
不够闪亮。Web 是一种非常直观的媒体,过去几年中许多新的浏览器功能都非常直观。如果新功能看起来不错,很容易说服某人尝试新功能。网络工作者完全是非视觉的;好处是抽象的。开发人员可能会明白,但对于大多数公司来说,关于花费时间和金钱来改进网站的决定是由非开发人员做出的,这使得网络工作者更难了解。
由于这个问题的大多数答案都是几年前的,所以这是我对截至 2019 年 5 月的当前状态的看法。
Web Workers 现在在通用浏览器中得到支持,我认为浏览器支持不再是它们使用的重大障碍。尽管如此,Web Workers 仍然不常用,而且我与之交互的大多数 Web 开发人员也不使用它们。
当然,并不是每个网站都需要做足够多的繁重工作来证明 Web Worker 的合理性。许多网站根本不需要JavaScript。因此,我不希望现实地在大多数网站中看到 Web Workers。
但是“繁重的工作”并不是证明 Web Worker 合理性的唯一因素——另一个是易用性。在许多情况下使用 Web Worker 是一项重大挑战。请注意,Web Worker API涉及将您的构建输出拆分为单独的文件,或fn.toString()
在运行时生成该代码(例如,使用 Data URI 或 )。Web 开发人员使用许多不同的构建系统,并且在他们的项目中经常有许多依赖项。配置项目以使用正确的依赖项创建这些额外的构建工件可能很困难,或者至少它会因您拥有的构建系统而异。
此外,这项工作几乎总是必须由每个 Web 开发人员针对每个单独的项目完成。如果在开发人员已经依赖的流行库和框架中普遍使用 WW,您可以期待更高的 Web Worker 采用率。但它们不是(出于与 API 相关的原因,如果我不得不猜测的话),即使对于执行大量同步工作的库也是如此。只要使用主线程是默认的、最简单的事情,大多数开发人员将继续这样做。
在工作人员中不支持大多数 API,这阻碍了他们在我的许多项目中的使用。
Firefox 在 v35 之前不会支持 Websocket,performance.now 在 v34 中,并且没有支持 IndexedDB 的日期。Chrome 最近才在 v38 中添加了 TextEncoder/Decoder,无法传递 ImageData。某些功能可以填充,但其他功能则不能,或者在解决目标时特别痛苦。
WebSockets 还没有完成。
我的意见:
但是当您需要在后台进行大量计算或运行繁重的进程时,您可以忽略旧浏览器,Web Workers 工作得非常好。
通常,有计算的网站是内网网站。大多数大公司使用微软的产品,他们使用 IE 作为浏览器。拥有最新版本的IE并不容易,因为升级会破坏许多内网网站。目前我的公司使用 IE 9,他们计划在 2 年内使用 IE 10.. 我有很多可以使用 Web Workers 的应用程序,但我不能,因为我没有 IE 10.. .