[jfam1]

I've been lurking hn for a while now but finally decided to register for this post. I actually did something similar to this for my undergrad honours thesis last year. The main difference being that my client was written in actionscript instead of javascript.

The difficulty with this type of application is breaking up the computation into chunks large enough to offset the overhead of getting the data to and from the client to net a "profit" in terms of computation time. As the author mentioned, you have to limit the amount of CPU time that the client uses, otherwise, you'll end up potentially impacting the user negatively. Couple this with the limited amount of time between a user's browser requests and the amount of computational power at your disposal is pretty limited.

Although my implementation was far from optimal (it was purely academic in order to see if the concept would work), I found that in every case, it was on the order of at least 100 times slower than simply doing the computation serially(!) on the server machine. It was actually costing more time to manage the connections between the various clients and the server than the amount of computational work that I was getting from the clients.

Now, it's not to say that something like this couldn't potentially be made to work. But the types of computations that this sort of grid is also severely limited. Due to things like sandboxing and socket restrictions you cannot (easily) have clients collaborate together to perform more complex computations, therefore you are effectively limited to embarrassingly parallel algorithms.