9 ms·
Hermes – A small JavaScript engine optimized for running React Native on Android
- Dibes 7y agoThey 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
- acoates 7y agoWe have done some internal tests of Hermes on a RN experience within Microsoft Office on Android. Currently we use V8 with bytecode caching on Android, since it provided better startup performance than the JSC engine that normally ships within RN. So the baseline is likely already faster than stock RN. V8 runtime Memory Impact: 30MB Hermes runtime memory impact: 21.5MB V8 time to interaction: 1.4s Hermes time to interaction: 1.1s We have done similar experiments on a full react-native-windows application, replacing the Chakra JS engine (also already with bytecode so faster than stock RN) with Hermes and had app boot time on a low end device go from 3.8s to 3.1s.
- writepub 7y agoFrom your numbers: 1. runtime memory reduction: ~25% 2. Boot time reduction: 20% 3. Time to interaction reduction: 20% For apps with significant boot times, and runtime memory consumption, this is valuable.
- r1nkgrl 7y agoFor apps with significant boot times, and runtime memory consumption, this is valuable. This assumes that the reductions are purely proportional to the total and not (at least partially) fixed.
- acostin 7y agoHave you also compared it with v8-lite? https://chromium.googlesource.com/v8/v8/+/84450a2239672109bcf537d6740b8babda521567 https://chromium.googlesource.com/v8/v8/+/84450a2239672109bc...
- ricardobeat 7y agoSince it's optimized for reducing memory consumption, you'd expect it to make boot time worse?
- hashseed 7y agoImpressive numbers. Did you try to use startup snapshot in V8 to improve TTI? https://v8.dev/blog/custom-startup-snapshots https://v8.dev/blog/custom-startup-snapshots
- snek 7y agoVery nice numbers, although worth mentioning hermes only appears to support es5, so there's way less stuff to load.
- simscitizen 7y agoHermes compiles JS ahead of time to bytecode. The VM takes bytecode in as input, not source code. The ES5 vs. ES6 distinction doesn't matter as much as in other engines where the runtime takes source code as input, and as a result has to pay the more expensive ES6 parsing cost at runtime.
- cztomsik 7y agoIt's a pity the Proxy is not supported mobx is really much nicer approach to state management and usually, apps using mobx are much faster - simply because implementing shouldComponentUpdate properly is hard
- wbercx 7y agoYou could still use MobX 4 though. It's equally well maintained.
- htormey 7y agoHere are some details on Hermes perf with sample code: https://mobile.twitter.com/htormey/status/1149353390230519809 https://mobile.twitter.com/htormey/status/114935339023051980... Here is a video comparing start times for a Hermes/non Hermes RN app: https://mobile.twitter.com/nparashuram/status/1149350214215462912 https://mobile.twitter.com/nparashuram/status/11493502142154... I’m currently at Chain React in Portland and they just gave a talk on Hermes. I tweeted a few screenshots that show other perf numbers/technical details for those who are interested.
- Dibes 7y agoThanks for the links!
- munificent 7y agoI understand and accept the reality of path dependence. 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.
- cx1000 7y agoThere's always skip http://www.skiplang.com/ http://www.skiplang.com/ > Skip is an experimental programming language developed at Facebook from 2015-2018.
- hnakamur 7y agohttps://github.com/skiplang/skip https://github.com/skiplang/skip > The Skip project concluded in 2018 and Skip is no longer under active development at Facebook.
- TAForObvReasons 7y agoEvery language involves tradeoffs. The initial JS tradeoffs were ok for the target audience and environments. A "carefully-designed language" in 2019 might hold up for 2019 use cases but we don't know whether the tradeoffs will make sense in 2029
- peteradio 7y agoCan't we be reasonably sure it will be better than a weekend spitball? (The most successful spitball of all time to give due credit)
- munificent 7y agoThis is generally true. Most languages were carefully designed and if they are disliked now, it's mainly because we've forgotten their original constraints in which the language's design made sense. (For example, header files in C are a reasonable approach when your compiler can't fit an entire source file in memory.) But JS and PHP aren't that. They both have a lot of good ideas in them but they are also both hampered by lots of initial mistakes in their design. JS because it was designed so quickly, PHP because it was cobbled together ad-hoc by someone who wasn't focused on the design of the language. Semicolon insertion in JS doesn't represent a smart trade-off from the past, it was just a bad design whose author didn't have time to fix it before it hit the marketplace [0]. Likewise, PHP's wildly inconsistent core library names aren't a sign of some thoughtful hidden order. They're because Rasmus lazily used strlen() as the hash function for strings and wanted them to go into different buckets [0]. [0]: https://brendaneich.com/2012/04/the-infernal-semicolon/ https://brendaneich.com/2012/04/the-infernal-semicolon/ [1]: https://news-web.php.net/php.internals/70691 https://news-web.php.net/php.internals/70691
- gtbono 7y agoOne 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. Will Hermes be able to solve this debugging issue?
- koala_man 7y agoDeveloper here. Yes, it will. JS code you debug through Chrome will still be running on Hermes.
- danabramov 7y agoHermes is using the same debugging protocol as Node. So yes, debugging in Chrome actually runs Hermes code on the device.
- danabramov 7y agoCorrection: this is not documented yet, but it should already work. Documentation is coming soon.
- simscitizen 7y agoThe current open-source release doesn't have the component that glues the RN inspector with the Hermes debugger to make on-device debugging of Hermes bytecode work. But Hermes does contain a debugger interface, and making this flow this work will happen sometime in the future.
- simscitizen 7y agoLooks like I was wrong and it’s just the docs that are missing.
- c-smile 7y agoNot clear what version of JS spec it supports. And what are these "optimizations for running React Native on Android". Just reducing startup/boot time or what?
- js2 7y agoThere'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. (For the unawares, RN necessarily uses the system JSC on iOS per Apple requirements, but for Android RN bundles JSC into the APK.) 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? 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?
- SkyMarshal 7y agoIt's not an unreasonable task for a small team of skilled engineers who know V8 in depth, the kind that FB can and probably has recruited. If they're taking most of what V8 learned over the years into account, they'll know what to prioritize and what to not to.
- aylmao 7y agoThey also probably know about the tradeoffs. V8 has to choose when interpret and when to compile, when to load things into memory, when to garbage-collect, etc. and they do so keeping in mind it is running javascript from the internet, for any kind of application, on any kind of device. Hermes can make many more assumptions and so the engineers, even if they built something very similar to V8, can probably dial the knobs much more differently to optimize for what Hermes cares about.
- koala_man 7y agoV8 and JSC are absolutely amazing pieces of technology. They'll run 60fps WebGL games or console emulators at incredible speeds. Huge props to the engineers that made that happen! RN apps are rarely CPU bound though, so they don't necessarily benefit as much from those same optimizations.
- londons_explore 7y agoAll those laggy react apps aren't CPU bound? What else is making them laggy?
- zenlibs 7y agoWorth noting that JSC on iOS for use in app-backend/business-logic code runs in interpreted mode [1]. Are Android versions of RN apps faster because Android's native V8 allows JIT, and Hermes also employs JIT? [1]: https://stackoverflow.com/questions/45422462/what-does-jit-is-disabled-mean-in-apples-javascriptcore-jsc-documentation https://stackoverflow.com/questions/45422462/what-does-jit-i...
- saghul 7y agoRN on Android also uses JSC, so no JIT. And, and per the video (https://www.youtube.com/watch?v=zEjqDWqeDdg&feature=youtu.be&t=130 https://www.youtube.com/watch?v=zEjqDWqeDdg&feature=youtu.be...) there is no JIT on Hermes either.
- sahrens2012 7y agoJSC on Android can use JIT, but some choose to disable it because it uses more memory than it’s worth.
- hajile 7y agoI'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.
- Shwanton 7y agoWill OTA updates with tools like Codepush still be possible with hermes? I'm assuming these tools push the minified js instead of compiled bytecode.
- KuhlMensch 7y ago(I knew nothing about this until 30 minutes ago, but I just did some quick research) A Quick zero-to-20mph Guide ============================ How it works ------------ 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. 2. Has no effect on application CPU performance 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 Results --------- Mattermost app 1. Time from load until first user interaction: 4.3s -> 2.3s 2. APK size: 41mb -> 22mb 3. Memory: 185Mb -> 136mb
- uponcoffee 7y agoFrom a similar high elevation perch: https://softwareengineering.stackexchange.com/questions/274640/why-is-android-runtimes-aot-compilation-more-performant-than-dalviks-jit https://softwareengineering.stackexchange.com/questions/2746... Tl;dr AoT can be more resource intensive as a one time cost while JIT uses and limits runtime resources
- moneil971 7y agoHere is the full post on Facebook’s Engineering blog: https://code.fb.com/android/hermes/ https://code.fb.com/android/hermes/