Guess: its output has more lines of JS than the vanilla JS versions, and since a lot of the variation between scripting languages in these things often come down to how fast they can stop running themselves and start running some underlying C, those extra lines hurt it.

This may also explain why JS is really fast in a couple of the examples. Those script likely do almost nothing but call some built-in function that does all its work in C (or C++, or whatever).

[EDIT] OK, if I'm reading these[1][2] files correctly, it has more to do with the the TS version being written in "modern" "idiomatic" "beautiful" JS with promises and crap, and the vanilla JS one being written in "ugly" "bad" old-school 90's-lookin' C-ish Javascript.

[1] https://github.com/greensoftwarelab/Energy-Languages/blob/ma...

[2] https://github.com/greensoftwarelab/Energy-Languages/blob/ma...

It seems to only be significantly different with fannkuch-redux. Looking at the CLBG page (http://benchmarksgame.alioth.debian.org/u32/performance.php?...) for that algorithm there doesn't seem to be very big difference at all.

I cannot explain the difference and if this is indeed an error by the authors of the paper it casts a fairly big shadow on the reliability of the rest of the data.

less optimal implementation is all