【问题标题】:Do we really need multi-threaded JavaScript?我们真的需要多线程 JavaScript 吗?
【发布时间】:2011-08-18 03:10:06
【问题描述】:

我最近听说Web Workers 规范定义了多线程 JavaScript 的 API。但是在使用客户端脚本这么长时间(和事件驱动范式)之后,我真的没有看到使用多线程的意义。

我可以看到 JavaScript 引擎和浏览器渲染引擎如何从多线程中受益,但我真的不认为将这种能力交给应用程序程序员有多大好处。

【问题讨论】:

  • 这至少应该是一个社区维基。
  • 我同意你的观点,我认为现在不需要它,因为一切似乎都是事件驱动的。但如果范式发生变化,我可以看到它的必要性。
  • 您可以对一段繁重的代码进行沙箱处理,以保持“主”窗口响应。在需要重新绘制屏幕或其中一部分之前需要进行大量计算的任何操作都可以在单独的线程中运行。你永远不需要它——但你也不需要蛋糕……

标签: javascript multithreading


【解决方案1】:

维基百科的文章实际上很好地回答了你的问题。

我们的开发人员拥有这项权力,因此我们可以专门将可能对用户造成干扰的任务交给网络工作者。浏览器不知道您的自定义界面需要哪些脚本才能正常运行,但您知道。

如果您有一个脚本会阻止页面呈现 10 秒,但对于网站运行而言并非必需,您可以将其卸载给网络工作者。这样做可以让您的用户与页面进行交互,而不是强迫他们等待 10 秒以执行该脚本。在某种程度上,它就像 AJAX 一样,可以在界面加载后注入东西,以免延迟用户的交互。

【讨论】:

  • 我在哪里可以得到这个wiki的链接我找不到它
  • 我明白你的意思,但我能想到的唯一计算密集型任务是渲染 3D...应该卸载到引擎本身。
  • 可以将 applicationCache 更新交给共享的 Web Worker 吗?它会在更新期间阻止浏览器。
  • @lightblade 有一堆处理可以交给工作人员,但不能交给浏览器引擎本身。图像处理操作、处理大量 JSON 或其他数据(例如阅读 hacks.mozilla.org/2011/03/nocomply)、音频样本合成、流体动力学模拟等等。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-03-20
  • 1970-01-01
  • 2023-03-31
  • 2012-12-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多