I think that Web Workers will soon be used to create distributed computing frameworks, there are some early attempts at this concept. Non-blocking code execution could have been done before using setTimeout, but it made a little sense as most browser vendors focused on optimizing their JS engines just recently. Now we have faster code execution and new features, so running some tasks unconsciously in background as we browse the web is probably just a matter of months ;)
There is something to be said for 'user rights' here. It sounds like you're describing a situation where the webmaster for Foo.com includes the script for, say, Folding@Home on their site. As a result, all visitors to Foo.com have some fraction of their CPU "donated" to Folding@Home, until they navigate away from Foo.com. Without some sort of disclaimer or opt-in, I would consider that a form of malware and avoid vising any site that did that.
That's not to say you couldn't build a system that asked for confirmation or permission, but there is definite potential for abuse.
I have pondered this myself in the context of item recommendation.
First, there is no problem with speed! JIT compiled javascript can be as fast as unoptimized C, especially for numeric code.
The bigger problem is that running javascript in the background will slow down the browser and therefore users may not like your website because it runs slowly.
There is obviously an issue of security, how can you verify the results?
And privacy, can you ensure sensitive data isn't compromised?
On top of this, it's quite a difficult thing to do. Can the number of visits you receive justify the effort that you'll have to put into it? It would be better if you could run the code transparently on either the server or client-side. Compiling other languages to javascript can help here.
In summary, the reason that it's not widespread is because developers' time is more valuable than server time. The risk of losing user data and the inconvenience to users outweighs the potential gains.
First that comes to my mind is security. Almost all distributed protocols that I know have encryption, thats why they prevent security risks. Although this subject is not so innovative..
I know of pluraprocessing.com doing similar thing, not sure if exactly javascript, but they run Java through browser and runs totally in-memory with strict security.
They have 50,000 computers grid on which they have successfully run applications even like web-crawling (80legs).
再比如，f(x)=12345，给出函数。 目的是求x的值。 我们可以通过用一些工人的结果替换 x 来测试它。 我认为一些无法验证的问题很难交给别人。
I think we can verify results on some kind of problem.
Let's say we have n number of items and need to sort it. We'll give it to worker-1, worker-1 will give us the result. We can verify it O(n) time. Please consider that it take at least O(n*log(n)) time to produce the result. Additionally we should consider how large is n items? (concern about network speed)
Another example, f(x)=12345, and function is given. Purpose is to find value of x. We can test it by replace x with some worker's result. I think some problems that are not verifiable are difficult to give to someone.
The whole idea of Javascript Distributed Computing has number of disadvantages:
single point of failure - there is no direct way to comunicate between nodes
natural fails of nodes - every node is working as long as browser
no guarantee that message sent will be ever received - according to natural fails of nodes
no guarantee that message received have been ever sent - because some hacker can interpose
annoying load on client side
ethical problems
while there is only one (but very tempting) advantage:
easy and free access to milions of nodes - almost every device has JS supporting browser nowadays
However the biggest problem is corelation between scalability and annoyance. Let's say you offer some attractive web service and run computing on client side. More people you use for computing, more people are annoyed. More people are annoyed, less people use your service. Well, you can limit annoyance (computing), scalability or try something between.
Consider google for example. If google will run computations on client side, some people will start to use bing. How many ? Depends on annoyance level.
The only hope for Javascript Distributed Computing may be multimedial services. As long as they consume lots of CPU, nobody will notice any additional load.
I think the no.1 problem is javascript inefficiency at computing. It wouldn't be just worth it, because an application in pure c/c++ would be 100 times faster.
我不久前发现了一个与此类似的问题，所以我构建了一个可以做到这一点的东西。 它使用网络工作者并动态获取脚本（但没有 Eval！）。 Web 工作人员对脚本进行沙箱处理，以便他们无法访问窗口或 DOM。 您可以在此处查看代码，以及主网站此处
该库在首次加载时有一个同意弹出窗口，因此用户知道后台发生了什么。
I found a question similar to this a while back, so I built a thingy that does this. It uses web workers and fetches scripts dynamically (but no Eval!). Web workers sandbox the scripts so they cannot access the window or the DOM. You can see the code here, and the main website here
The library has a consent popup on first load, so the user knows what's going on in the background.
发布评论
评论（9）
我认为Web Workers很快就会被用来创建分布式计算框架，有一些对此概念的早期尝试。 非阻塞代码执行本来可以在使用 setTimeout 之前完成，但它有点有意义，因为大多数浏览器供应商最近才专注于优化他们的 JS 引擎。 现在我们有了更快的代码执行速度和新功能，因此当我们浏览网页时，在后台无意识地运行一些任务可能只需要几个月的时间；）
I think that Web Workers will soon be used to create distributed computing frameworks, there are some early attempts at this concept. Non-blocking code execution could have been done before using setTimeout, but it made a little sense as most browser vendors focused on optimizing their JS engines just recently. Now we have faster code execution and new features, so running some tasks unconsciously in background as we browse the web is probably just a matter of months ;)
这里有一些关于“用户权利”的内容。 听起来您正在描述这样一种情况：Foo.com 的网站管理员在其网站上包含了例如 Folding@Home 的脚本。 因此，所有 Foo.com 的访问者都会将其 CPU 的一部分“捐赠”给 Folding@Home，直到他们离开 Foo.com。 如果没有某种免责声明或选择加入，我会认为这是一种恶意软件，并避免访问任何这样做的网站。
这并不是说您不能构建一个要求确认或许可的系统，但肯定存在滥用的可能性。
There is something to be said for 'user rights' here. It sounds like you're describing a situation where the webmaster for Foo.com includes the script for, say, Folding@Home on their site. As a result, all visitors to Foo.com have some fraction of their CPU "donated" to Folding@Home, until they navigate away from Foo.com. Without some sort of disclaimer or opt-in, I would consider that a form of malware and avoid vising any site that did that.
That's not to say you couldn't build a system that asked for confirmation or permission, but there is definite potential for abuse.
我自己在项目推荐的背景下思考过这个问题。
首先，速度没有问题！ JIT 编译的 javascript 可以与未优化的 C 一样快，特别是对于数字代码。
更大的问题是，在后台运行 javascript 会减慢浏览器的速度，因此用户可能不喜欢您的网站，因为它运行缓慢。
显然存在安全问题，如何验证结果？
还有隐私，你能确保敏感数据不被泄露吗？
除此之外，这是一件非常困难的事情。 您收到的访问次数能否证明您为此付出的努力是值得的？ 如果您可以在服务器端或客户端上透明地运行代码，那就更好了。 将其他语言编译为 javascript 可以在这里提供帮助。
总而言之，它没有广泛普及的原因是开发人员的时间比服务器时间更有价值。 丢失用户数据的风险和给用户带来的不便超过了潜在的收益。
I have pondered this myself in the context of item recommendation.
First, there is no problem with speed! JIT compiled javascript can be as fast as unoptimized C, especially for numeric code.
The bigger problem is that running javascript in the background will slow down the browser and therefore users may not like your website because it runs slowly.
There is obviously an issue of security, how can you verify the results?
And privacy, can you ensure sensitive data isn't compromised?
On top of this, it's quite a difficult thing to do. Can the number of visits you receive justify the effort that you'll have to put into it? It would be better if you could run the code transparently on either the server or client-side. Compiling other languages to javascript can help here.
In summary, the reason that it's not widespread is because developers' time is more valuable than server time. The risk of losing user data and the inconvenience to users outweighs the potential gains.
我首先想到的是安全。
我所知道的几乎所有分布式协议都具有加密功能，这就是它们防止安全风险的原因。 虽然这个主题不是那么创新..
http://www.igvita.com/2009/03/03/collaborative-map-reduce-in-the-browser/
另外Wuala是一个分布式系统，使用java applet实现。
First that comes to my mind is security.
Almost all distributed protocols that I know have encryption, thats why they prevent security risks. Although this subject is not so innovative..
http://www.igvita.com/2009/03/03/collaborative-map-reduce-in-the-browser/
Also Wuala is a distributed system, that is implemented using java applet.
我知道 pluraprocessing.com 正在做类似的事情，不确定是否完全是 javascript，但他们通过浏览器运行 Java，并且完全在内存中运行，具有严格的安全性。
他们拥有 50,000 台计算机网格，在这些计算机上成功运行应用程序，甚至像网络爬行（80 条腿）一样。
I know of pluraprocessing.com doing similar thing, not sure if exactly javascript, but they run Java through browser and runs totally in-memory with strict security.
They have 50,000 computers grid on which they have successfully run applications even like web-crawling (80legs).
我认为我们可以验证某种问题的结果。
假设我们有 n 个项目并且需要对其进行排序。 我们将它交给worker-1，worker-1会给我们结果。 我们可以验证它 O(n) 时间。 请考虑至少需要 O(n*log(n)) 时间才能产生结果。 另外我们应该考虑n项有多大？ （关心网络速度）
再比如，f(x)=12345，给出函数。 目的是求x的值。 我们可以通过用一些工人的结果替换 x 来测试它。 我认为一些无法验证的问题很难交给别人。
I think we can verify results on some kind of problem.
Let's say we have n number of items and need to sort it. We'll give it to worker-1, worker-1 will give us the result. We can verify it O(n) time. Please consider that it take at least O(n*log(n)) time to produce the result. Additionally we should consider how large is n items? (concern about network speed)
Another example, f(x)=12345, and function is given. Purpose is to find value of x. We can test it by replace x with some worker's result. I think some problems that are not verifiable are difficult to give to someone.
Javascript 分布式计算的整个理念有很多缺点：
，而只有一个（但非常诱人）优势：
但是最大的问题是可扩展性和烦恼之间的相关性。 假设您提供一些有吸引力的 Web 服务并在客户端运行计算。 你使用越多的人进行计算，就会有越多的人感到烦恼。 更多的人感到恼火，更少的人使用你的服务。 好吧，你可以限制烦恼（计算）、可扩展性或尝试介于两者之间的东西。
以谷歌为例。 如果 google 在客户端运行计算，有些人就会开始使用 bing。 多少 ？ 取决于烦恼程度。
Javascript 分布式计算的唯一希望可能是多媒体服务。 只要它们消耗大量 CPU，就没有人会注意到任何额外的负载。
The whole idea of Javascript Distributed Computing has number of disadvantages:
while there is only one (but very tempting) advantage:
However the biggest problem is corelation between scalability and annoyance. Let's say you offer some attractive web service and run computing on client side. More people you use for computing, more people are annoyed. More people are annoyed, less people use your service. Well, you can limit annoyance (computing), scalability or try something between.
Consider google for example. If google will run computations on client side, some people will start to use bing. How many ? Depends on annoyance level.
The only hope for Javascript Distributed Computing may be multimedial services. As long as they consume lots of CPU, nobody will notice any additional load.
我认为第一个问题是 javascript 计算效率低下。 这不仅仅是值得的，因为纯 c/c++ 中的应用程序会快 100 倍。
I think the no.1 problem is javascript inefficiency at computing. It wouldn't be just worth it, because an application in pure c/c++ would be 100 times faster.
我不久前发现了一个与此类似的问题，所以我构建了一个可以做到这一点的东西。 它使用网络工作者并动态获取脚本（但没有 Eval！）。 Web 工作人员对脚本进行沙箱处理，以便他们无法访问窗口或 DOM。 您可以在此处查看代码，以及主网站此处
该库在首次加载时有一个同意弹出窗口，因此用户知道后台发生了什么。
I found a question similar to this a while back, so I built a thingy that does this. It uses web workers and fetches scripts dynamically (but no Eval!). Web workers sandbox the scripts so they cannot access the window or the DOM. You can see the code here, and the main website here
The library has a consent popup on first load, so the user knows what's going on in the background.