Video yükleniyor...
Video Yüklenemedi
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... show more
77,248 görüntüleme • 8 ay önce •via X (Twitter)
42 Yorum
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.
![Graph Convolutional Network by hand ✍️ ~ 12 steps walkthrough below Graph Convolutional Networks (GCNs), introduced by Thomas Kipf and Max Welling in 2017, are the tool for data shaped like a graph: social networks, recommendations, biological networks, drug discovery, molecular chemistry. I drew and calculated a simple GCN entirely by hand. Goal: run a two-layer GCN, then a small classifier, on a five-node graph, filling in every cell yourself. 1. Given A graph of five nodes, A to E, with edges between some of them. 2. Adjacency matrix (neighbors) Put a 1 wherever two nodes share an edge, in both directions. 3. Adjacency matrix (self) Add 1s down the diagonal, one self-loop per node. That is just adding the identity matrix. 4. Messages Multiply each node's embedding by the weights and biases, then ReLU. Negatives become 0. 5. Pooling Multiply the messages by the adjacency matrix. Each node gathers the messages of its neighbours and itself. 6. Visualize Node A pools [3,0,1] + [1,0,0] = [4,0,1]. 7. Second GCN layer Messages again: weights, biases, ReLU. 8. Pooling again Pool over each node and its neighbours, once more. 9. Visualize Node C pools [1,2,4] + [1,3,5] + [0,0,1] = [2,5,10]. 10. Fully connected layer Weights, biases, ReLU. This time there are no neighbours to pool, just the node itself. 11. Linear layer One more: weights and biases. 12. Sigmoid Squash each score to a probability (≥ 3 → 1, 0 → 0.5, ≤ -3 → 0). That is the classification for each node. You have just classified every node in the graph by hand. ✍️ The outputs: A: 0 (very unlikely) B: 1 (very likely) C: 1 (very likely) D: 1 (very likely) E: 0.5 (neutral) The takeaway: a GCN layer is two parts. The top part pools each node with its neighbours through the adjacency matrix. The bottom part is an MLP that transforms each node on its own. A transformer layer has the same two parts, with an attention matrix where the adjacency matrix was. Both matrices do one job, mixing across positions: attention over tokens, adjacency over nodes. In my class I call the GCN the transformer's little cousin: a bit more stubborn, because its attention is fixed by the graph rather than computed from Q, K, and V. Draw the two side by side and the resemblance is hard to miss. 💾 Save this post! #AIbyHand #GraphNeuralNetworks #DeepLearning](https://image.24vids.com/tw-2077396566864773414/ext_tw_video_thumb/2077396555410051073/pu/img/JX9U_Rk-wmgd1S-x.jpg)
