Even without the JIT restriction, you wouldn’t be able to beat JSC as it’s one of the fastest runtimes out there, pretty much level with V8.
Static Hermes sounds like a different prospect, though, if it’s able to use TS annotations to compile to mostly-static native code. That could be great for genuinely high-performance TS code. (Although you wouldn’t want to immediately shackle it to React Native...)
We've seen the opposite for networking related activities especially when there are 100's of requests that can happen on certain screens. We've tried using Hermes but didn't see any differences other than the app bundle increasing in size.
From what I've seen Kotlin(and Swift prob also) semantics are fare more AOT-compile friendly so they're probably a fair bit ahead (depending on how much you gimp your JS target to mimic Asm.JS/Wasm but most regular JS developers won't write code that way).
Wasm isn’t a great target for JS.
At first, it sounds really promising, like "wow, all the overhead is fixed". Until you get to the bottom and see:
"Currently the only built-ins that we support this for are mostly limited to the math built-ins."
So all those terrible "before" graphs mostly still apply today for most DOM interaction and browser APIs. A few more pieces still aren't done for that to work well. This has some pointers to current state: https://stackoverflow.com/questions/62587845/wasm-dom-access...
"Static Hermes is the the next major version of Hermes, still under active development. It enables optional ahead-of-time native compilation of soundly typed JavaScript, using TypeScript or Flow type annotations."
I find the AI images in this presentation to be quite distracting for some reason.
Hermes is meant to address some of those concerns and this is probably the next step towards improving those metrics.
[0] https://speakerdeck.com/tmikov2023/static-hermes-react-nativ...