Questions about TypeScript compatibility and Hermes[main] support

[NiuGuohui]

I tried out Static Hermes today, and I’m really excited about the performance! However, during the testing process, I had some questions:
It seems like the current version of SH only supports TypeScript at a very basic level. Features like interface, IntersectionType, Class inheritance, and many other syntax features don't seem to be supported.
I understand that fully supporting all TypeScript syntax is nearly impossible, but I’m wondering about SH's future development. Will it continue to improve TypeScript syntax compatibility (it almost feels like you're building a TypeScript runtime)? Or is there a compatibility solution (such as using a JS compiler to remove highly flexible and unsupported TypeScript syntax before SH compilation)?
Additionally, I’d like to understand whether the development of SH will continue to impact the progress of the current Hermes main version. I noticed that the Hermes version seems to have not updated its language feature support for quite a while, including support for things like Async functions, ES modules, Classes, and method definitions that were mentioned in the documentation some time ago.

[tmikov]

Hi,
Let me address your question about the main branch first. It has been in maintenance mode for at least two years now, with only critical bug fixes and API compatibility changes. All development is in the static_h branch, which is much more powerful, feature complete, faster, more correct, etc. It is used by Meta internally, it can be used by React Native today with some manual tweaking (Software Mansion has already released a fork that does it), and it will become the default in RN in 2025.

You mentioned ESM. Unfortunately that is a very complicated topic which is out of our hands, because it depends on modifying the existing bundlers. For some more details:

• Support for import/export at runtime #1382 (comment)
• top-level await not supported #1481 (comment)

Your other question was about TypeScript support.

We intend to eventually support as much of TypeScript as we can, however it is not our primary focus at the moment, because we are concentrating on completing the basics of the sound type system. When that is finished, we will eventually gradually map more TS features to it. Keep in mind that TypeScript is an extremely complicated language, and a lot of its features (like structural typing) are not compatible with a fast and sound typed implementation.

[NiuGuohui]

So, based on what you've said, in a real project, even if our code strictly follows SH's syntax, we might still encounter some performance bottlenecks. For example, if we use third-party JS/TS libraries (like lodash) that don’t have an SH-compatible version, this would cause them to fall back to regular JS interpretation.

The TS/Flow source-to-SH syntax conversion tool I mentioned earlier is actually intended to address such scenarios. By using this tool, we could convert the code in a way that preserves the sound type system’s syntax while removing unsupported TS syntax, so that more code snippets can be optimized during SH compilation.

Of course, I understand that this may not be the core focus of SH, since the tool I mentioned could probably be implemented as just a Babel plugin. :-)

[tmikov]

that don’t have an SH-compatible version, this would cause them to fall back to regular JS interpretation.

Typed code can't just silently fall back to regular JS. If you are compiling something in typed mode, it has to follow the SH typechecker rules, or there would be a compilation error. Additionally, typed and untyped code cannot directly share types, because that would break soundness.

The TS/Flow source-to-SH syntax conversion tool I mentioned earlier is actually intended to address such scenarios. By using this tool, we could convert the code in a way that preserves the sound type system’s syntax while removing unsupported TS syntax, so that more code snippets can be optimized during SH compilation.

Writing such a tool would be more difficult than writing Static Hermes. It would be a significant scientific achievement...

[NiuGuohui]

If you are compiling something in typed mode, it has to follow the SH typechecker rules, or there would be a compilation error.

I successfully executed some regular JavaScript code on shermes. Although the code didn't use the sound type, resulting in not-so-high execution efficiency, I noticed that it seems that SH also supports compile regular JavaScript code.

Additionally, typed and untyped code cannot directly share types, because that would break soundness.

That is to say, can't SH be compatible with the current JS/TS ecosystem? Does all code have to be rewritten based on the sound type system?

[tmikov]

SH is fully compatible with current JS. It supports two modes: typed (the new stuff) and untyped (good old JavaScript). They can be mixed and can talk to each other, but the sound types, which typed mode relies on, cannot be instantiated directly by untyped code, or that would cause unsoundness.

The idea is that one should use typed mode to optimize hot spots, or to write new code.

[NiuGuohui]

The idea is that one should use typed mode to optimize hot spots, or to write new code.

Alright, I now have a better understanding of the future usage scenarios for SH. I'm looking forward to seeing how SH performs when integrated into projects in the future!
Thank you for taking the time to clarify my doubts.