@tmikov Not many, you’re right about that. I could see the job market drastically reduce but not disappear.
Definitely important to be aware of that cognitive trap. I’d say equally as important to recognize that humans have a terrible track record of predictions too.
@tmikov@jamonholmgren@MohitKarekar Maybe this is how Static Hermes works but would having unsound types still help short-circuit the expected paths while still leaving all the real runtime possibilities as fallback paths?
@drosenwasser@longtilwrong@robpalmer2 We've seen a spike from 10gb to 24gb, I'm guessing due to the parallel checkers. But this tweet makes me think this is unusual
RNLConf is happening on November 13-14! 🇬🇧
There will be talks from some of the best speakers around, including @CipolleschiR, @jmeistrich, @kadikraman and @SaadNajmi .
Use my discount code MIKE10 when getting your ticket 👇
https://t.co/BvfwP1LGpU
Legend List 2.0 is now in beta!
✨ Improved performance
✨ Perfectly accurate scrollToIndex
✨ Mount time on new arch goes from pretty fast to ZERO
✨ Sticky headers
✨ estimatedItemSize is now optional
✨ Fixes many bugs
@kentcdodds Have you tried brewfile - https://t.co/qkvJ1HMVgC? It allows you to just execute a single file and install / update a bunch of dependencies. Example from my dotfiles - https://t.co/Cd6XRXGffX. I just run `brew bundle` in the folder and everything is done for me 😁
Together with Hermes team we're working on enabling Static Hermes in React Native apps ⚛️
Initial benchmarks show 16% faster startup on production app 🚀
Try it for yourself with build scripts from our Hermes fork: https://t.co/NWSUSPdUry
People periodically ask on GitHub when we will add Wasm support to Hermes - that is the ability for Hermes to execute Wasm as well as JS. One suggested solution is to use one of the excellent existing Wasm runtimes like Wasmer.
I just wrote a pretty long response and thought it is worth sharing here as well.
WebAssembly (Wasm) is excellent for platform-neutral code distribution and achieving near-native performance, for example in browsers or containers. However, for native apps, Wasm's utility is not so obvious, since the app is already targeting a native platform and doesn't need the extra layer.
Then there is the issue of latency and cost. Wasm is not ideal for fast interpretation because it acts more like a binary representation of an abstract syntax tree (AST) rather than a binary language designed for interpretation. This means that using Wasm involves either a slow interpreter or upfront JIT compilation, both of which go against Hermes' design goals of rapid startup, minimal latency and predictable performance.
The binary size of Hermes also has to be considered. Wasm engines like Wasmer are actually larger than Hermes itself, so "adding" a Wasm engine on top of Hermes would at least triple the binary size, which is quite ironic considering Hermes' compact size.
Furthermore, integrating Wasm into a JavaScript engine is not as easy as it might appear, because new versions of Wasm that include garbage collection require a very tight integration with the JS engine.
It’s also not necessarily true that Wasm is faster than Hermes bytecode. Static Hermes has a native backend and JIT tuned for the bytecode. If Wasm code were translated to Asm.js and then compiled with Hermes, it would leverage our optimizing compiler.
While our focus hasn't been Asm.js optimization (there are two main issues: integer support and specialized access to the memory array buffer), the incremental effort of support these is less than integrating a separate Wasm engine, especially considering all the factors I described above.
Therefore, the recommended approach is transpiling Wasm to Asm.js, which Static Hermes can then compile either to bytecode or native.
To illustrate my point, I performed a little experiment. It is not super representative, but shows the idea. I wrote the following mini-benchmark in C:
With some timing code, invoked with 𝚋𝚎𝚗𝚌𝚑(𝟺𝚎𝟼, 𝟷00), compiled with Clang -O3, it executes in 278 ms.
Then I compiled the same function to Wasm and converted it to JS:
I got the following JS:
I added some timing code, compiled to bytecode, and:
1. Executed it with the Static Hermes jit:
𝚜𝚑-𝚑𝚎𝚛𝚖𝚎𝚜 -𝚇𝚏𝚘𝚛𝚌𝚎-𝚓𝚒𝚝 𝚋𝚎𝚗𝚌𝚑.𝚓𝚜
It ran in 406 ms.
2. Compiled to native with Static Hermes:
𝚜𝚑𝚎𝚛𝚖𝚎𝚜 𝚋𝚎𝚗𝚌𝚑.𝚓𝚜 -𝚘 𝚋𝚎𝚗𝚌𝚑 && ./𝚋𝚎𝚗𝚌𝚑
It ran in 266 ms.
To recap:
- C version with Clang -O3: 270 ms.
- Asm.js + Static Hermes JIT in forced mode: 410 ms.
- Asm.js + Static Hermes native: 270 ms.
The difference between Static Hermes native and C is within the noise on my Mac, so I consider them the same and rounded all of the times.
Now, this is not a very good benchmark: it only uses doubles and it doesn't access memory, but it demonstrates the idea.
@ThePrimeagen There is another side though. I make a point of proclaiming my ignorance and how I don’t understand things (when I don’t) because I think it dismantles the “pro” culture where people are afraid to appear dumb for not knowing things
@ThePrimeagen Looking forward to finishing this. One thing stood out to me - the hate towards the “I don’t know what I’m doing” meme.
Now I don’t know anyone who uses it to truly wash their hands of any competence but I’m curious if it is being perceived that way more widely.
@jamonholmgren I'd still love to compiled JS down to native for CLIs and tooling, not only on-device. Imagine a world where you can write the typescript compiler in TS but run it "natively". It would bring the ecosystem closer to rust/native without the costs