Hermes: Any plan to propose a node-hermes Node.js variant?

[AMorgaut]

Is there any plan to propose a node-hermes Node.js variant as we have today node-chakracore ?

[mhorowitz]

Hi, thanks for asking! tl;dr is no. Let me elaborate.

Hermes optimizes for its primary metrics of startup time, size, and memory utilization. These aren't specific to React Native, but they were informed by it. In a long-running server environment, key metrics are different. Startup time an app size are only of minor importance. Servers are not nearly as memory constrained as mobile phones.

Hermes makes different trade-offs than other VMs in order to optimize for its core metrics. In particular, Hermes has no JIT (just in timer compiler), because JITs are mainly useful for improving the performance of longer running, CPU intensive programs. A JIT also consumes more memory than an interpreter. In a server environment, where you're trying to optimize for CPU and QPS over a longer time period, a JIT is likely to help improve your metrics.

Given all this, we don't believe Hermes is likely to be competitive as an engine for node, and so we don't have any plans to propose anything like this.

[ljharb]

However, it would still be useful for people who want to run CI in node using hermes without needing an android simulator or device.

[mhorowitz]

Running React Native code requires the native RN infrastructure, and I'm not aware of anybody having made this work in a Node environment. That is already a barrier to running CI for React Native code in node, so I think nobody is doing it today.

If someone in the community has a need for this, there's no reason they shouldn't be able to build it. I don't think it should require changes to Hermes, but we would consider PRs to Hermes if it was useful. It's just not something we plan to do.

[AMorgaut]

Hermes optimizes for its primary metrics of startup time, size, and memory utilization. These aren't specific to React Native, but they were informed by it. In a long-running server environment, key metrics are different. Startup time an app size are only of minor importance. Servers are not nearly as memory constrained as mobile phones.

Thanks, this helps to clarify the main target metrics of Hermes.

Just take into account that Node.js is not server-specific

It is even I guess more widely and heavily used for tools like ESLint, Babel, Webpack, Packer, and so much more, than for server-side application (for which competition with PHP, Java, .NET, python, ruby, ... makes it still a little player)

(mainly CLI but not only)

I'm not sure how much time has the JIT to optimize the code during such quick and intensive JS executions. We are not in a context where the engine has a lot of free time between user interactions.

It is also used to build:

• standalone / client apps, like with NW.js or Electron.
• embedded apps, in other devices than mobiles, like with Espruino or low.js

[urbien]

Hermes optimizes for its primary metrics of startup time, size, and memory utilization. These aren't specific to React Native, but they were informed by it. In a long-running server environment, key metrics are different. Startup time an app size are only of minor importance. Servers are not nearly as memory constrained as mobile phones.

@mhorowitz AWS Lambda (serverless), and similar on Azure and Google Cloud has the same optimization needs as React Native. It is a short lived process that needs very low memory footprint. Amazon even created a special VM manager, FireCracker, to quickly create a destroy the whole environment, optimized for lowest possible CPU and memory usage, as every extra megabyte used, and extra 100ms is the money lost in capacity utilization of such cloud applications.

[tmikov]

It would be a pretty cool project for the community to implement. A similar approach to node-chakracore would probably work well. We (the Hermes team) would be happy to answer questions, review PRs, etc, but as @mhorowitz said, there are no plans to take it on as a project ourselves.