I understand and accept the reality of path dependence.<p>At the same time, when I see projects like his, V8, HHVM, etc. I can't help but wonder where we could be if all of that engineering effort had gone into more carefully-designed languages.
There's a gazillion engineering hours between JavaScriptCore and V8. It seems crazy to write a JS engine from scratch as opposed to forking JSC or V8.<p>(For the unawares, RN necessarily uses the system JSC on iOS per Apple requirements, but for Android RN bundles JSC into the APK.)<p>I don't understand how Hermes will differ from JSC/V8 in terms of functionality and performance. What functionality can be left out of Hermes as compared to JSC/V8 in order to shrink its sie?<p>What sorts of performance improvements will Hermes have that wouldn't similarly benefit JSC/V8, and why wouldn't Apple/Google include those in their own engines?
One of the game-breaking things about the older JavaScriptCore engine on Android was that when I debug on Chrome, it has a totally different engine (V8) so, there were code that ran correctly when debugging but crashed on-device.<p>Will Hermes be able to solve this debugging issue?
I'm moderately curious about why the language of choice was C++ rather than Rust. It seems like all the Ocaml people at Facebook would prefer a more ML-like language.
Here is the full post on Facebook’s Engineering blog: <a href="https://code.fb.com/android/hermes/" rel="nofollow">https://code.fb.com/android/hermes/</a>
(I knew nothing about this until 30 minutes ago, but I just did some quick research)<p><i>A Quick zero-to-20mph Guide</i><p>============================<p>How it works<p>------------<p>1. Results in less to load into memory WHY? It has no Just-in-time (JIT) compilation, instead compiles to bytecode ahead-of-time (AOC). By comparison most (all?) modern browsers have a tricky blend of both.<p>2. Has no effect on application CPU performance<p>3. Chrome debugger will connect DIRECTLY to the Hermes engine within the app (simulator or device). By comparison, Chrome debugger uses its own V8 engine to execute code, instead of the JsCoreEngine (?) that React-native uses by default<p>Results<p>---------<p>Mattermost app<p>1. Time from load until first user interaction: 4.3s -> 2.3s<p>2. APK size: 41mb -> 22mb<p>3. Memory: 185Mb -> 136mb
Worth noting that JSC on iOS for use in app-backend/business-logic code runs in interpreted mode [1].<p>Are Android versions of RN apps faster because Android's native V8 allows JIT, and Hermes also employs JIT?<p>[1]: <a href="https://stackoverflow.com/questions/45422462/what-does-jit-is-disabled-mean-in-apples-javascriptcore-jsc-documentation" rel="nofollow">https://stackoverflow.com/questions/45422462/what-does-jit-i...</a>
They harp a lot on how fast it starts up - which sounds great - but I would like to have some solid numbers on what that startup time actually is on actual devices! I can't seem to find anything perusing around the GH page or the site
Will OTA updates with tools like Codepush still be possible with hermes? I'm assuming these tools push the minified js instead of compiled bytecode.
Not clear what version of JS spec it supports.<p>And what are these "optimizations for running React Native on Android". Just reducing startup/boot time or what?