Announcing Hermes-node Hermes can now run as a standalone CLI with Node.js-compatible APIs - no C++ embedding required. Technically, hermes-node is a Node.js API compatibility layer for Hermes. It ports Node's native bindings (fs, net, http, child_process, etc.) to Node-API and reuses Node's original lib/*.js files, allowing standard Node.js... programs to run on Hermes instead of V8. It vendors libuv, c-ares, llhttp, Ada, simdutf, etc to provide the same networking and I/O stack as Node, and runs as a standalone CLI binary. In this demo: - REPL with tab completion - TypeScript HTTP server using http, fs, and path - Type annotations stripped natively by the parser — no transpiler, not even a built-in one. This is still a work in progress, though surprisingly functional. More Node modules coming, source will be published soon.show more

very impressive Did you do this via implementing v8’s C++ API similar to node-jsc?

My goal wasn't to drop-in replace v8 in Node, so I went in the opposite direction. I am porting and partially re-implementing Node C++ bindings. So, instead of putting Hermes in Node, I am adding Node modules to Hermes, so to speak. This gives me better control over the architecture and more "ownership" over the result. I am pretty excited about adding sound typing to the Node modules and compiling them natively. End result is potentially almost everything written in typed JS, with very little C++.

@jarredsumner What is the perf impact of using modules to interface. Any penalty

@jarredsumner Sorry, I don't understand the question. Can you elaborate?

@jarredsumner I was just asking if there is a performance penalty to doing it with modules instead of swapping out chrome for hermes

@jarredsumner What do you mean by "modules"?

@jarredsumner You said you’re “adding node modules to hermes”. So I’m asking any perf penalty in doing that as opposed to switching chrome to hermes

@jarredsumner It is hard to say - can't compare performance against a hypothetical. Switching Node to Hermes requires shimming the v8 API, which I haven't looked into.

Cool

Really exciting. In Vladimir's PR to add Node-API support to Hermes, we needed a way to run unit tests from the Node.js repo on Hermes. Vladimir ended up writing a "lite" Hermes Node.js for that (and I contributed child process support for POSIX!). Asking what this means for us.

this is amazing

Wait, so, a smaller Electron?😍

Ability to run tests and benchmarks in Hermes directly will be a killer feature.

I’ve been waiting for something like this. Will this also work with static Hermes somehow? I.e. can we AOT compile Node.js bindings? (Are they even well typed enough?) Also curious what’s the Meta use case for this..? Or is it more of an open ended exploration / Hermes extension

I developed it in my free time. Yes, compiling typed .js is very much part of the plan.

int32, int64, float32, float64, shared memory multithreading, static memory layout objects. Small list left for the greatest lang ever.

Amazing 🧐

Nice, been wanting this for a while - excited to see where you take it

Super excited about this! 🚀 Been following your work on Hermes & Static Hermes for a while coming from Meta and leading the engine that powers React Native, you know exactly what’s missing in the JS runtime space. hermes-node feels like the perfect bridge: fast startup, tiny footprint, native TS support, and real Node compatibility. This has huge potential for CLI tools, edge/serverless, scripts, and even pushing performance further with Static Hermes later. Extremely bullish on this project. Can’t wait to see where it goes and to play with the source. Great work Tzvetan!

@tmikov is there any source or binary to try? 🤩

Soon. I have been busy with other stuff... 🤷

Wooow this is really cool 🔥

Wow you have been cooking recently! Very impressed.

was waiting for this for years!

So cool

cool stuff! 👏

is there something that Tzvetan can't cook? 🔥

@grok give me the technical implications of this

@birch_js 👀

Binary size?

It is literally the first thing shown in the video - 8.8 MB.

Woooh🤯

@grok поясни что тут такого особенного? В чем соль?

This is very nice! And actually a very similar approach in theory of what we did with Edge.js: Would love to bring Hermes into it and collaborate further 🤗

finally

any news? 🙏

You say it ports Node's native bindings (fs, net, http, child_process, etc.) to Node-API: Is this using Vladimir's / Microsoft's Node-API implementation or did you build that yourself as part of this?

It is a new implementation. Primarily because the other one wasn't ready to merge, but I also needed better control in order to iterate quickly and be able to easily customize it. I don't know yet which I will end up using. Or perhaps a union of the two.

What's your current view on the questions I raised here? you said the runtime-specific APIs are "specific to Node.js and so they cannot be part of Hermes". Do you no longer consider them out of scope?

I imagine it will defer much of their implementation to the hermes_napi_host in the hermes-node target (and eventually React Native or the react-native-node-api package).

1. This doesnt mean those apis would work on react native right? 2. Would those modules work on windows? Or just unix?

IMHO, RN for desktop would benefit a lot from simply being built on top of this runtime. The situation on mobile is more nuanced because of binary size and trickier integration, but I see benefits there too. However I want to be clear that as of now there are no plans for that. I would welcome such plans. Re Windows: it isn't my focus right now, but there is no reason why it couldn't run there, with some effort.