(Tack on another order of magnitude or two if we're talking about something like GPU computation, which I would not yet trust in WebGL, even ignoring the problem of bandwidth for the problem specification. If you work the math, it becomes difficult to overcome orders of magnitude in performance differences by throwing lots of slow resources at a problem, because you get to the point where it becomes impossible to make up the difference due to additional communication overheads.)
This basically limits this "supercomputer" to embarrassingly parallel problems that have very small specifications, for which performance is no particular concern, including the fact that one does not even know how much resources you will have for the problem on a second-by-second basis. This is not a large niche, but it can be fun.
> his basically limits this "supercomputer" to embarrassingly parallel problems that have very small specifications
note support for map-reduce so it goes a step beyond "embarrassing" (map).
> It's hard to imagine a workload in which this would be the truly best solution.
Biology offers a few examples - typically (alignment-free) sequence analysis is limited by memory, not by communication, so being able to reach a large number of volunteers may be more significant that the time it takes for each of them to communicate their piece of the problem. Here's an example: http://www.almob.org/content/7/1/12
asm.js may overcome that to some extent, but as I mentioned elsewhere, the real problem is bandwidth. Frankly you could run things effectively instantaneously on the client side, and still end up with wildly worse performance on this sort of cluster than a real supercomputer.
As for bandwidth, there is no reason to believe that bandwidth is an issue for all parallel architectures. Stream processing works very well under the given constraints, for example.
And even if your JS is running at native speeds, it doesn't solve the bandwidth problem, which is nowadays arguably the distinguishing characteristic of a supercomputer, since the compute nodes of a supercomputer are hardly any faster than a commodity desktop anymore. (Some, yes, sure, but nowhere near the multiples there used to be.)