If you look at the code it's not using WebWorkers. It's pretty unfair to compare single threaded vs multithreaded. I don't know how JS would perform with better code but it'd certainly be better than 40x slower.
And then there is a bias in those benchmarks, see for example the ones for quicksort: in Python they only time the duration of the sort itself, whereas (at least in Julia and JS) they time both the creation of the random array and the time needed to sort it.
It's not just that. It's that there's no concept of a vector or matrix at all, and no operator overloading to allow these concepts to be introduced into the language in an idiomatic way. You could put these things into a bastardized JavaScript JIT, but that seems at least as awkward as Julia.
I thought about this a little bit, and I don't think this would be very trivial. CoffeeScript is designed to map easily onto JavaScript. A transcompiler that compiles JavaScript with matrix extensions to performant plain JavaScript would likely be significantly more complex than the CoffeeScript transcompiler.
Consider that you want to translate the matrix operation A * B into A.times(B). You have two options:
1) Figure out what's a matrix before runtime, using static type inference.
2) Translate the code into JavaScript that determines whether to treat the code as a matrix at runtime.
In the first case, you don't need a JIT at all. JITs exist largely because you can't do perfect type inference in dynamic languages. If you can do perfect type inference on all acceptable code (a la RPython), or if you require type annotations, you can compile straight to C or machine code.
You can probably get acceptable performance out of combining static type inference with guards. My understanding is that this is what SpiderMonkey does internally. But at this point, it might be easier to integrate your functionality into an existing JIT than to write your transcompiler with type inference, particularly since you will have to implement matrix and vector ops inside the JS engine to achieve acceptable performance anyway.
More to the point - who cares. All these languages are hopelessly slow. If performance matters do it in a performant language like C++, C or FORTRAN. If it does not matter - then it does not matter and so stop going on about it.
No, it does matter. A lot of scientific computation is one-time-use code. What one cares about is the amount of time to write, execute, and debug the code. If it will take you much less time to write the code in a high-level language (which is usually the reason people use high-level languages), it may very well be worth the 2x performance hit from Julia, or even the larger performance hits of MATLAB and R. Additionally, when the amount of time spent performing vector and matrix operations greatly exceeds the amount of time spent in the interpreter, most of these languages will be as fast as C.
I write MATLAB code that takes 5 minutes to run on a regular basis. If I were to write it in C, I would lose productivity, because it would take much more than 5 minutes longer to write. If I were to write it in Julia, it would probably take about the same amount of time to write, but I would hypothetically have the results in a few seconds. That matters.