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

21–30 of 57 posts

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

#21

Post by hnakamur »

cx1000 wrote: post #7
munificent wrote: post #6

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.

There's always skip http://www.skiplang.com/ > Skip is an experimental programming language developed at Facebook from 2015-2018.

https://github.com/skiplang/skip

> The Skip project concluded in 2018 and Skip is no longer under active development at Facebook.

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

#22

Post by snek »

acoates wrote: post #5
Dibes wrote: post #2

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

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…

Very nice numbers, although worth mentioning hermes only appears to support es5, so there's way less stuff to load.

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

#23

Post by snek »

munificent wrote: post #6

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.

I'd like to introduce you to my religion.

https://webassembly.org/

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

#24

Post by ricardobeat »

acostin wrote: post #11
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…

Have you also compared it with v8-lite? https://chromium.googlesource.com/v8/v8/+/84450a2239672109bc...

Since it's optimized for reducing memory consumption, you'd expect it to make boot time worse?

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

#25

Post by munificent »

lootsauce wrote: post #20
munificent wrote: post #6

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.

It's a perfectly valid sentiment but... Comments like this annoy me because, as I get older (turned 40 this year surpassing 20 years of web development) I've noticed variants of it come up many times a year in various contexts and it often feels like so much useless hand wringing and lamenting. In my experience shoulda, coulda, wouldas will get you bupkis in this world. Kinda like how a great idea is worth pretty muc…

> it often feels like so much useless hand wringing and lamenting.

Not every comment on the Internet needs to be actionable, but sure.

> Further, language design does not imply better products.

That's fair, but we aren't talking about products here. We're talking about an announcement of a language implementation. Jazz records won't cure cancer, but that doesn't mean we can't talk about jazz.

Not defending any language design or any technical choices over others here at all, just saying if you want to see a change in the state of things sentiments like this are more like eating popcorn while you watch the world go by.

My day job is working on a language, for what it's worth, so I can both eat popcorn and work to change the state of things.

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

#26

Post by munificent »

TAForObvReasons wrote: post #8
munificent wrote: post #6

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.

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

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/

[1]: https://news-web.php.net/php.internals/70691

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

#27

Post by janic »

c-smile wrote: post #19

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?

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.

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

#28

Post by simscitizen »

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.

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

#29

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

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

#30

Post by orange8 »

BinaryIdiot wrote: post #16
munificent wrote: post #6

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.

This is what I always go back to. We have so many smart engineers working on ways to interpret JS to interact with native components and try to tighten that loop to make it faster. Why is there not a large movement to just make UI development in native languages better? Like, Swift UI looks great but it appears to be a huge exception to what everyone else wants to do. I'd love to see more work go towards making cross…

> Why is there not a large movement to just make UI development in native languages better

What are these native languages you speak of?

Post reply on HN