Luckily, the Safari version of WebCL we use has integrated buffer sharing (https://github.com/SRA-SiliconValley/webkit-webcl). I'd expect that to be in the Chrome port being developed. The Nokia port for Firefox a couple years back didn't have it, though I don't know what's going on with the new one @ https://www.khronos.org/bugzilla/show_bug.cgi?id=792 .
My benchmarks show that asm.js + workers + webgl will have that 5-10ms hit, but otherwise performs at similar scales. If we figure out streaming data transfers to overlap communication with computation, it would be even less.
The graphics pipeline consists of programmable and semi-fixed components and it is quite often useful to interact with it. For that purpose compute shaders introduce compute kernels, atomic counters, atomic locks, sharable buffers and some hookups to the pipeline stages.
This is functionality gleaned from Cuda, but repackaged in a more or less portable way. Of course compute shader kernels aren't as flexible as either Cuda or OpenCL programs. However OpenCL is by now quite far behind "the state of the art".
Targeting CUDA/OpenCL/WebCL was so that we can rely upon intermediate GPGPU compilers. Our DSL compiler outputs a bunch of for-loops, which traditional compilers love to optimize (the JIT for JS, LLVM for OpenCL, etc.). If we targeted a low-level language such as nvidia's PTX, I suspect we'd still want something like LLVM inbetween. Is there a good preprocessor for compute shaders?
It's true that WebGL does not have compute shaders (and neither does OpenGL ES), yet.
However OpenGL ES roughly tracks OpenGL's development with OpenGL ES 2.0 == OGL 2.0, OpenGL ES 3.0 == OGL 3.0, in each case with a bunch of features stripped but with the essential advances in place. OpenGL ES 4.0 which should come about in the next 2-3 years is very likely to include compute shaders.
I'd suggest solving a few fundamental problems with the technology first, sorry to rain on the parade.