It would be good for Static Hermes if it could use pure JavaScript code(that has no type annotations) with automatic type guessing like "var" code in Dart, or ":=" in Go.

[Foxchandaisuki]

It will make Static Hermes possible to use much more existing libraries, which are written in pure JavaScript and has no proper type annotations.

[avp]

We're designing Static Hermes typed code to be interoperable with existing untyped JS for use with existing libraries, to allow for gradual or partial conversion to typed code.

Inferring and enforcing static types onto untyped code which was not written with static types in mind would be difficult. We can't be sure of the intent of a programmer who thought they were writing untyped (potentially highly dynamic) JS. We do currently do some type inference in the optimization pipeline of the compiler, though - this allows us to emit special instructions when we know you're adding numbers, for instance. There's no runtime checks inserted, this is solely for optimization based on known types.

We do intend to allow some static type inference within typed JS (with certain fallbacks to any type) to allow for easier migration to typed JS and easier authoring. While Static Hermes is still a work in progress, even today var x = [1, 2, 3] will infer that the type of x is number[] in JS code compiled with -typed.

[Foxchandaisuki]

We're designing Static Hermes typed code to be interoperable with existing untyped JS for use with existing libraries, to allow for gradual or partial conversion to typed code.

Inferring and enforcing static types onto untyped code which was not written with static types in mind would be difficult. We can't be sure of the intent of a programmer who thought they were writing untyped (potentially highly dynamic) JS. We do currently do some type inference in the optimization pipeline of the compiler, though - this allows us to emit special instructions when we know you're adding numbers, for instance. There's no runtime checks inserted, this is solely for optimization based on known types.

We do intend to allow some static type inference within typed JS (with certain fallbacks to any type) to allow for easier migration to typed JS and easier authoring. While Static Hermes is still a work in progress, even today var x = [1, 2, 3] will infer that the type of x is number[] in JS code compiled with -typed.

Is it possible to migrate existing RN apps running on the Hermes Engine to a fully compiled native binary app, which requires no Virtual Machine like Hermes, without any code changes?

[tmikov]

Is it possible to migrate existing RN apps running on the Hermes Engine to a fully compiled native binary app, which requires no Virtual Machine like Hermes, without any code changes?

Yes, that is already possible, but it is not beneficial. At the moment, untyped code in Static Hermes executes between 0% to 20% faster than Hermes. The resulting binary is very large, because native code is several times larger than the corresponding bytecode.

[Foxchandaisuki]

Another question: Is it able to make native binary server application with Static Hermes?

2024년 3월 13일 (수) 오전 4:17, Tzvetan Mikov @.***>님이 작성:

Is it possible to migrate existing RN apps running on the Hermes Engine to a fully compiled native binary app, which requires no Virtual Machine like Hermes, without any code changes?

Yes, that is already possible, but it is not beneficial. At the moment, untyped code in Static Hermes executes between 0% to 20% faster than Hermes. The resulting binary is very large, because native code is several times larger than the corresponding bytecode.

— Reply to this email directly, view it on GitHub https://github.com/facebook/hermes/issues/1349#issuecomment-1992369859, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4E3THC3OBRIAAM27VDG3MTYX5IFLAVCNFSM6AAAAABER4KPISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSGM3DSOBVHE . You are receiving this because you authored the thread.Message ID: @.***>

[tmikov]

Yes. Although we are not recommending that, it is certainly possible.

[Foxchandaisuki]

Yes. Although we are not recommending that, it is certainly possible.

I found your comment https://github.com/facebook/hermes/issues/60#issuecomment-1749813168 telling there will be no Node API, including file system support of Static Hermes.

Is your plan changed? Will React Native support File System and other Node API?

On Thu, Mar 14, 2024 at 12:17 AM Tzvetan Mikov @.***> wrote:

Yes. Although we are not recommending that, it is certainly possible.

— Reply to this email directly, view it on GitHub https://github.com/facebook/hermes/issues/1349#issuecomment-1994642169, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4E3THHKI2RAS2TAJV2LOPTYYBU2FAVCNFSM6AAAAABER4KPISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJUGY2DEMJWHE . You are receiving this because you authored the thread.Message ID: @.***>

[tmikov]

Static Hermes is a JS compiler and engine. It is the equivalent of v8 (JSC, SpiderMonkey, etc). File APIs fall outside of the JS engine responsibility.

Node is not the same as v8, it is a completely separate project by different people (not even the same company) which uses v8 and implements various APIs on top of it. If there is a Node API implementation for Static Hermes, it will not originate from our team.

With that said, Static Hermes makes it very easy to access the existing system APIs (fopen, etc), so in many cases the Node API wouldn't even be necessary.