网络工作者与承诺 [英] web workers vs promises

问题描述

为了使Web应用程序响应，您使用异步非阻塞请求。我可以设想两种方法来实现这一点。一种是使用延迟/承诺。另一个是网络工作者。对于Web工作者，我们最终会引入另一个进程，并且我们不得不来回传输数据。我正在寻找某种性能指标，以帮助了解何时选择简单的非阻塞回调而不是网络工作者。

In order to make a web app responsive you use asynchronous non-blocking requests. I can envision two ways of accomplishing this. One is to use deferreds/promises. The other is web workers. With web workers we end up introducing another process and we incur the overhead of having to marshal data back and forth. I was looking for some kind of performance metrics to help understand when to chose simple non-blocking callbacks over web workers.

是否有某种方法可以在不使用两种方法的原型？我在网上看到很多关于网络工作者的教程，但我没有看到很多成功/失败的故事。我所知道的是我想要一个响应式应用程序。我正在考虑使用Web worker作为内存数据结构的接口，该数据结构可能是0.5-15MB（本质上是数据库），用户可以查询和更新。

Is there some way of formulating which to use without having to prototype both approaches? I see lots of tutorials online about web workers but I don't see many success/failure stories. All I know is I want a responsive app. I'm thinking to use a web worker as the interface to an in-memory data structure that may be anywhere from 0.5-15MB (essentially a db) that the user can query and update.

当我理解javascript处理时，可以执行一个长时间运行的任务并将其切片，以便它定期产生控制，允许其他任务处理一段时间。这会是使用网络工作者的标志吗？

As I understand javascript processing, it is possible to take a single long-running task and slice it up so that it periodically yields control allowing other tasks a slice of processing time. Would that be a sign to use web workers?

推荐答案

延期/承诺和Web工作者满足不同需求：

Deferred/Promises and Webworkers address different needs:

• 延迟/保证是用于为尚未提供的结果分配引用的构造，以及组织在结果可用或返回失败时运行的代码。

• Deferred/promise are constructs to assign a reference to a result not yet available, and to organize code that runs once the result becomes available or a failure is returned.

Web工作者异步执行实际工作（使用操作系统线程而非进程 - 因此它们的重量相对较轻）

Web workers perform actual work asynchronously (using operating system threads not processes - so they are relatively light weight)

换句话说，JavaScript是单线程的，你不能异步使用延迟/承诺运行代码 - - 一旦代码运行完成承诺，就不会运行其他代码（您可以更改执行顺序，例如使用setTimeout（），但这不会使您的Web应用程序本身更具响应性）。不过，你可能会以某种方式通过例如创建异步查询的错觉。通过每隔几毫秒递增索引来迭代一个值数组（例如使用setInterval），但这几乎不可行。

In other words, JavaScript being single threaded, you cannot use deferred/promises to run code asynchronously -- once the code runs that fulfills the promise, no other code will run (you may change the order of execution, e.g. using setTimeout(), but that does not make your web app more responsive per se). Still, you might somehow be able to create the illusion of an asynchronous query by e.g. iterating over an array of values by incrementing the index every few milliseconds (e.g. using setInterval), but that's hardly practical.

为了异步执行查询等工作因此，从应用程序的UI中卸载此工作，您需要实际异步工作的东西。我看到了几个选项：

In order to perform work such as your query asynchronously and thus off load this work from your app's UI, you need something that actually works asynchronously. I see several options:

• 使用 IndexedDB 提供异步API，

运行您自己的内存数据结构，并使用Web worker，如您所示，要执行实际查询，

run your own in-memory data structure, and use web workers, as you indicated, to perform the actual query,

使用服务器端脚本引擎，例如 NodeJS 运行代码，然后使用客户端ajax启动查询（以及处理结果的承诺），

use a server-side script engine such as NodeJS to run your code, then use client-side ajax to start the query (plus a promise to process the results),

使用数据库可通过HTTP访问（例如Redis，CouchDB），并从客户端发出异步GET（即ajax）来查询数据库（以及处理结果的承诺），

use a database accessible over HTTP (e.g. Redis, CouchDB), and from the client issue an asynchronous GET (i.e. ajax) to query the DB (plus a promise to process the results),

使用例如开发混合Web应用程序 Parse

develop a hybrid web app using e.g. Parse

哪种方法是在你的情况下最好的？很难说没有确切的要求，但这里是我要看的尺寸：

Which approach is the best in your case? Hard to tell without exact requirements, but here are the dimensions I would look at:

• 代码复杂性 - 如果你已经拥有数据代码结构，可能是Web工作者很合适，否则IndexedDB看起来更合理。


• 性能 - 如果你需要一致的性能，服务器端实现或数据库似乎更合适


• 体系结构/复杂性 - 您希望所有处理都在客户端完成，还是您可以负担管理服务器端实现的工作？

我发现这本书有用的阅读。

这篇关于网络工作者与承诺的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！