Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hermes – A small JavaScript engine optimized for running React Native on Android

github.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Hermes – A small JavaScript engine optimized for running React Native on Android

#51

Post by wbercx »

cztomsik wrote: post #50
acoates wrote: post #5

Earlier quoted context omitted.

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 inte…

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

You could still use MobX 4 though. It's equally well maintained.

Re: Hermes – A small JavaScript engine optimized for running React Native on Android

#52

Post by 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

Re: Hermes – A small JavaScript engine optimized for running React Native on Android

#53

Post by simscitizen »

simscitizen wrote: post #28
gtbono wrote: post #13

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?

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

Looks like I was wrong and it’s just the docs that are missing.

Re: Hermes – A small JavaScript engine optimized for running React Native on Android

#54

Post by uponcoffee »

KuhlMensch wrote: post #52

(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 performan…

From a similar high elevation perch: 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

Re: Hermes – A small JavaScript engine optimized for running React Native on Android

#55

Post by eyko »

BinaryIdiot wrote: post #37
orange8 wrote: post #30

Earlier quoted context omitted.

> Why is there not a large movement to just make UI development in native languages better What are these native languages you speak of?

> What are these native languages you speak of? Really any of them. Swift UI is the only example I can think of where a group of folks are working on making UI easy and intuitive to create and manage inside of a native language. Why is there not an effort to make something as intuitive in C++ or GO or Rust? C++ would probably be the hardest one, sure, and there are many UI frameworks for all of these languages but no…

There are probably more JavaScript developers (not necessarily professional developers, just people writing JavaScript) than C++, Go and Rust combined, so it's just more likely that the ecosystem with more momentum will get more interest and resources.

I'm sure Facebook could have written React Native in C, C++, Go, Java or Rust, but take a guess at what the adoption rate and the hype around it would have been...

If Netscape/MS browser in the 90s had shipped with an embedded, sandboxed JVM with native browser APIs, then maybe the world would be very different today, but we work with what we have don't we all?

Re: Hermes – A small JavaScript engine optimized for running React Native on Android

#57

Post by sahrens2012 »

saghul wrote: post #49
zenlibs wrote: post #34

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

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

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