Live data from Hacker News

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

github.com

11–20 of 57 posts

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

#11
post #5
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…

Have you also compared it with v8-lite?

https://chromium.googlesource.com/v8/v8/+/84450a2239672109bc...

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

#12

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 mean Lua[1] exists, predates Javascript[2], is incredibly fast[3] and can be easily embedded[4]. I've personally shipped production game titles where the whole game state + logic was inside a 400kb block on a PSP where you only had 8MB of system ram, and this was before LuaJIT.

Sadly, developer familiarity and ecosystem/mindshare sometimes dominate technical constraints, at least that's how we ended up with Javascript everywhere.

[1] https://en.wikipedia.org/wiki/Lua_(programming_language)

[2] https://en.wikipedia.org/wiki/JavaScript

[3] https://luajit.org/

[4] https://github.com/vvanders/wasm_lua

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

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

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

#14
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?

Developer here. Yes, it will. JS code you debug through Chrome will still be running on Hermes.

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

#15
post #5
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…

Impressive numbers. Did you try to use startup snapshot in V8 to improve TTI? https://v8.dev/blog/custom-startup-snapshots

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

#16

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 platform UI easier to do in native languages. I feel like you could get a lot more mileage out of that, especially if you add WASM as a compilation target, then you can get the same ubiquity that JS has.

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

#17
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…

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

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

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

#18
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?

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

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

#20

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

The problem is much bigger than the design of a language, the problem is producing something (not a language) people will use and growing software systems that meet varying demands as those products evolve in a way that is affordable. Of course there are all sorts of tradeoffs to make these things happen, most of which have nothing to do with idealized whiteboarding and language design. That stuff often irrelevant when you take into consideration all the various kinds of other situation-specific details people face to make things lots of people use.

That goes the same for products and for languages. And of course the two classes of processes co-evolve. Further, language design does not imply better products. It is tangential to all the other things that make a product happen. You have to hire good people, you have to identify meaningful problems and provide better solutions. You have to get it in front of people and you have to adapt over time to your core audience's needs. Use lua use php use C# whatever you do all your choices including that one need to be self supporting of each other. The developers have experience in x, y is what runs on the platform, devs more often know a than b and so are cheaper to find. Language design matters not in those scenarios.

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. Kind of like when you have an open source project and get requests for fixes but no pull requests. The most viable open source is build by a community of collaborators and is easy for new collaborators to join in and contribute to. If you don't have a community of users that care about your project it does not matter what technical decisions you make, what language you use and what design it follows.

So what matters more than language design is problem solving and community and getting more pull requests than the other guy, more conversions than the other app and shoulda, coulda, wouldas are popcorn on the theater floor.

Post reply on HN