
Hermes – A small JavaScript engine optimized for running React Native on Android - smoser
https://github.com/facebook/hermes
======
munificent
I 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.

~~~
TAForObvReasons
Every 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

~~~
munificent
This 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
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.

Will Hermes be able to solve this debugging issue?

~~~
danabramov
Hermes is using the same debugging protocol as Node. So yes, debugging in
Chrome actually runs Hermes code on the device.

~~~
danabramov
Correction: this is not documented yet, but it should already work.
Documentation is coming soon.

------
js2
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.

(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?

~~~
pso
The same real world react app went from 40MB to 20MB.

They don't ship minified javascript to final app, but bytecode, which they say
is 1/3 smaller (both minified). They have moved the parse and compile stages
to ahead of time, making the VM smaller, and giving the bytecode benefit. The
bytecode benefit also means a quicker time to live/first reponse from 4s to 2s
in their example.

Link to the talk, from FB employee announcement made at React Conference
today, 15 minutes length. Linked 2 mins in, because the audio is poor to
start.

[https://youtu.be/zEjqDWqeDdg?t=130](https://youtu.be/zEjqDWqeDdg?t=130)

~~~
js2
Ah, gotcha. It's moving the parse/compile AOT that I missed. Naively, I'm
still surprised they didn't start with JSC/V8 but maybe those engines carry a
lot more in them than is needed. Thank you for the link.

------
hajile
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.

------
moneil971
Here is the full post on Facebook’s Engineering blog:
[https://code.fb.com/android/hermes/](https://code.fb.com/android/hermes/)

------
KuhlMensch
(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
From a similar high elevation perch:
[https://softwareengineering.stackexchange.com/questions/2746...](https://softwareengineering.stackexchange.com/questions/274640/why-
is-android-runtimes-aot-compilation-more-performant-than-dalviks-jit)

Tl;dr AoT can be more resource intensive as a one time cost while JIT uses and
limits runtime resources

------
zenlibs
Worth 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-i...](https://stackoverflow.com/questions/45422462/what-does-jit-is-
disabled-mean-in-apples-javascriptcore-jsc-documentation)

~~~
saghul
RN on Android also uses JSC, so no JIT. And, and per the video
([https://www.youtube.com/watch?v=zEjqDWqeDdg&feature=youtu.be...](https://www.youtube.com/watch?v=zEjqDWqeDdg&feature=youtu.be&t=130))
there is no JIT on Hermes either.

~~~
sahrens2012
JSC on Android can use JIT, but some choose to disable it because it uses more
memory than it’s worth.

------
Dibes
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

~~~
acoates
We 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.

~~~
cztomsik
It'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
You could still use MobX 4 though. It's equally well maintained.

------
Shwanton
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.

------
c-smile
Not 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?

~~~
janic
The VM doesn't run JS directly, just bytecode so the version of the spec
supported doesn't matter much. JS can be run through babel before going
through the Hermes compiler.

~~~
brainee
wonderful

