4 ms·

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

by js2 7y ago

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?

SkyMarshal 7y ago
It'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 ago
  They 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 ago
V8 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 ago
  All those laggy react apps aren't CPU bound? What else is making them laggy?
  - jaquers 7y ago
    Poor coding practices, bad state management, and lack of encapsulation between UI components and business logic / data retrieval. It's really easy to build a React Native app, but not easy to build a really good one.
BinaryIdiot 7y ago
> What functionality can be left out of Hermes as compared to JSC/V8 in order to shrink its sie? At the moment Hermes isn't compatible with ES6 (it's missing a lot of stuff). Perhaps, since part of the build step for RN anyway is transpiling, they don't need to provide all of ECMA's features. ES5 is more simple, less complex so I wonder if some performance can be had there. But since they are building an engine strictly for making native apps using JS, there may be shortcuts or other stuff they can drop that JSC/V8 normally have to worry about but that's just speculation. I'd love to see more info addressing your questions!
pso 7y ago
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
- aylmao 7y ago
  This is actually huge and will probably only get better, especially considering now they own their whole JS stack: the framework (React/RN), the language (Flow [1]) and now the VM. It sounds like Hermes is exclusively for running React Native on mobile. They could start building React directly into Hermes— the reconciling algorithm for example, or maybe even some real parallelism. Very curious to see how all this keeps evolving. [1]: https://github.com/facebook/flow https://github.com/facebook/flow
- js2 7y ago
  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.
sahrens2012 7y ago
Proof is in the pudding: 28% startup speed improvement in MS Office for Android vs V8 with bytecode caching (so AOT compiling the bytecode isn’t a big advantage specific to Hermes): https://news.ycombinator.com/item?id=20413046 https://news.ycombinator.com/item?id=20413046 The key is that Hermes is optimized for a totally different environment and workload - RN apps from disk on slow Android devices vs. websites downloaded on desktop computers. The fact that Hermes is architected for RN from the beginning is key. Bytecode is as compact as possible, and is mmap’d. mmap’d bytecode is a very deep change with huge benefits, but also limits some optimizations other engines rely on, such as inline caching. Also note Hermes does not have a JIT to save memory and APK size. A lot of the heroic perf work in V8/JSC is in the JIT which is not useful in most RN scenarios/environments.

by js2 7y ago

SkyMarshal 7y ago

It'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 ago
They 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 ago

V8 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 ago
All those laggy react apps aren't CPU bound? What else is making them laggy?
- jaquers 7y ago
  Poor coding practices, bad state management, and lack of encapsulation between UI components and business logic / data retrieval. It's really easy to build a React Native app, but not easy to build a really good one.

BinaryIdiot 7y ago

> What functionality can be left out of Hermes as compared to JSC/V8 in order to shrink its sie? At the moment Hermes isn't compatible with ES6 (it's missing a lot of stuff). Perhaps, since part of the build step for RN anyway is transpiling, they don't need to provide all of ECMA's features. ES5 is more simple, less complex so I wonder if some performance can be had there. But since they are building an engine strictly for making native apps using JS, there may be shortcuts or other stuff they can drop that JSC/V8 normally have to worry about but that's just speculation. I'd love to see more info addressing your questions!

pso 7y ago

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

aylmao 7y ago
This is actually huge and will probably only get better, especially considering now they own their whole JS stack: the framework (React/RN), the language (Flow [1]) and now the VM. It sounds like Hermes is exclusively for running React Native on mobile. They could start building React directly into Hermes— the reconciling algorithm for example, or maybe even some real parallelism. Very curious to see how all this keeps evolving. [1]: https://github.com/facebook/flow https://github.com/facebook/flow
js2 7y ago
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.

sahrens2012 7y ago

Proof is in the pudding: 28% startup speed improvement in MS Office for Android vs V8 with bytecode caching (so AOT compiling the bytecode isn’t a big advantage specific to Hermes): https://news.ycombinator.com/item?id=20413046 https://news.ycombinator.com/item?id=20413046 The key is that Hermes is optimized for a totally different environment and workload - RN apps from disk on slow Android devices vs. websites downloaded on desktop computers. The fact that Hermes is architected for RN from the beginning is key. Bytecode is as compact as possible, and is mmap’d. mmap’d bytecode is a very deep change with huge benefits, but also limits some optimizations other engines rely on, such as inline caching. Also note Hermes does not have a JIT to save memory and APK size. A lot of the heroic perf work in V8/JSC is in the JIT which is not useful in most RN scenarios/environments.