I'm trying to understand how Static Hermes works underneath.

[Please-just-dont]

I've looked through the code, and as far as I can tell Static Hermes is doing roughly following when you type shermes ./my_js_code:

1. Parsing Typescript/Javascript and creating a temporary C file (it's turning the source code into C source code).
2. Then calls (on my system) /usr/bin/cc. So it calls the system's compiler on the C code.

Is this correct? Also what is LLVH that's referenced in Static Hermes. I'm aware of LLVM, but what is LLVH?

[avp]

Yes, the shermes binary basically runs the full Hermes compiler pipeline and then uses a backend that outputs C instead of a backend that outputs Hermes Bytecode. You can also compile typed code to Hermes Bytecode by using the hermes tool with the -typed flag.

llvh is just our internal vendored version of LLVM (renamed to avoid namespace conflicts with llvm)

[Please-just-dont]

@avp OK. What is the backend that outputs C? Is it contained within the Static Hermes project? Or does it call out to an external program? I know the actual compilation of C is done by calling /user/bin/cc, so it uses the system C compiler.

[avp]

lib/BCGen/SH/SH.cpp contains the backend to output to C.

[Please-just-dont]

@avp So ALL of the work done to translate Javascript/Typescript/Flow to C is done in SH.cpp? The file is only 3000 lines long. If so that's impressive. Also, when do you think there'll be some documentation on how this works or at least how to use it? A couple of years?

[tmikov]

We don't have plans to document the internals of the compiler in detail - it is all open source and there already are various docs under https://github.com/facebook/hermes/tree/static_h/doc.

It would be nice to have more detailed user instructions on how to use the shermes tool, but for now our efforts are focused on implementation. If someone in the community is good at writing user documentation, PRs are welcome.

Meanwhile we have some blog posts and efforts from the community that can provide additional information:

• https://tmikov.blogspot.com/2023/09/how-to-speed-up-micro-benchmark-300x.html
• https://github.com/thejustinwalsh/sh-raylib
• https://x.com/tmikov/status/1871397866327203845

[Please-just-dont]

@tmikov I know it wasn't the original intention, but a tool like this is probably going to generate a lot of interest as simply a 'faster' Javascript engine in any context or use, outside of React Native usage.

[tmikov]

Sure, that's why we have given a couple of talks about it:

• https://speakerdeck.com/tmikov2023/static-hermes-react-native-eu-2023-announcement
• https://speakerdeck.com/tmikov2023/optimizing-with-static-hermes-chain-react-2024
  (There are also YouTube videos for both talks).

Note that compiling untyped JS to native AOT isn't a performance improvement over a high tier JIT like JSC or v8. Even with typed code, the win isn't guaranteed. It is more about getting predictable performance than being faster in absolute terms.