His table shows js is 40x slower on matrix multiplication.
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.
If the underlying engine is fast, a more convenient syntax can be introduced.
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.
In the second case, you take a speed hit of 25-50% on scalar operations for the guard, at least in modern versions of SpiderMonkey and V8 (see http://jsperf.com/cost-of-multiplication-via-function).
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.
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.