Web Workers为什么不使用更多？

Question

网络工作者是我不时反对的技术,无论是作为博客文章的主题,还是在演示文稿中提及.

在我参加的最近一次演讲中,发言人谈到了网络工作者:

我不确定他们为什么不再使用它们.

我意识到,考虑到这一点,对于具有如此明显优势和 用例的技术,网络工作者似乎采用了相当缓慢或狭窄的采用方式.

Web工作者是否存在一些固有的问题,使它们变得不那么有用？我只是在错误的地方寻找他们使用的例子吗？或者是Javascript程序员一般不习惯于创建多线程应用程序.

Answer 1

他们使用不多的主要原因(在我看来):

1. 惯性.它们是一种相对较新的技术,人们还没有花时间去学习它们.你去讨论它,这意味着你已经走在了前面; 那里有很多人甚至还没有听过"网络工作者"这个词,更不用说编写它们了.

2. 浏览器兼容性 较旧的浏览器不支持它们.大多数人仍然需要为他们的网站支持至少IE8,所以不能使用这样的技术.

3. 何必？使用新技术的唯一原因是它解决了问题或实现了新的东西.大多数网站对网络工作者没有任何实际需求.或者即使他们这样做,他们也没有看到需要.

4. 不够光泽.网络是一种非常直观的媒体,过去几年中许多新的浏览器功能都非常直观.如果它看起来不错,很容易说服别人尝试新功能.网络工作者完全是非视觉的; 好处是抽象的.开发人员可能会得到它,但对于大多数公司来说,关于花费时间和金钱来改进网站的决定是由非开发人员做出的,这使得网络工作者更难以查看.

Answer 2

由于这个问题的大多数答案已有几年的历史，以下是我对截至 2019 年 5 月的现状的看法。

Web Workers 现在在通用目标浏览器中得到支持，我认为浏览器支持不再是它们使用的重大障碍。尽管如此，Web Workers 仍然不常用，我接触的大多数 Web 开发人员都不使用它们。

当然，并不是每个网站都需要做足够多的繁重工作来证明 Web Worker 的合理性；许多网站根本不需要JavaScript。因此，我不希望在大多数网站中看到 Web Workers 真实存在。

但“繁重”并不是证明 Web Worker 合理的唯一因素——另一个因素是易用性。在许多情况下使用 Web Workers 是一个重大挑战。请注意，Web Worker API涉及将您的构建输出拆分为单独的文件，或fn.toString()在运行时生成该代码（例如，使用数据 URI 或）。Web 开发人员使用许多不同的构建系统，并且在他们的项目中通常有许多依赖项。配置项目以使用正确的依赖项创建这些额外的构建工件可能很困难，或者至少它会因您拥有的构建系统而异。

此外，对于每个单独的项目，这项工作几乎总是必须由每个 Web 开发人员完成。如果 WW 在开发人员已经依赖的流行库和框架中普遍使用，您可以期待更高的 Web Worker 采用率。但它们不是（出于与 API 相关的原因，如果我不得不猜测的话），即使对于执行大量同步工作的库也是如此。只要使用主线程是默认的、最容易做的事情，大多数开发人员就会继续这样做。