SoylentNews is people
SoylentNews
Submitted via IRC for AnonymousLuser
Facebook open-sources Hermes JavaScript engine to improve React Native Android app performance
Facebook is continuing its open-sourcing spree with the launch of a new JavaScript engine designed to improve the performance of big apps on Android devices, the company announced today at the Chain React conference in Portland, Oregon.
Mobile apps are getting increasingly larger, which can pose problems — particularly for devices with limited storage or processing power. This is one reason many big tech firms, including Spotify, Uber, and Facebook itself, have taken to launching “lite” versions of their apps. But what if developers could improve the performance of their main apps by using an optimized JavaScript engine that reduces the download size and boosts startup performance?
That’s what Facebook set out to do first with its own suite of apps, for which it developed the Hermes JavaScript engine, which is now available on GitHub for any developer to use.
“To increase the performance of Facebook’s apps, we have teams that continuously improve our JavaScript code and platforms,” the company wrote in a blog post. “As we analyzed performance data, we noticed that the JavaScript engine itself was a significant factor in startup performance and download size. With this data in hand, we knew we had to optimize JavaScript performance in the more constrained environments of a mobile phone compared to a desktop or laptop.”
According to Facebook, Hermes helps improve three core app attributes: time-to-interact (TTI), which is the time it takes from launching an app to when it becomes fully loaded and usable; download size (Android .APK size); and memory utilization.
(Score: 3, Interesting) by FatPhil on Wednesday July 17 2019, @10:10PM
However, I think that Javascript is a fine language for "apps", mobile or not, if those are the kinds of things that you want to be interacting with. With a rich enough native library, there's very little reason to write high level code in anything but an easily-patchable scripting language. The existence of a text edit box in an app shouldn't incur more than one additional line in the app's source to create it, and one to read its value. Everything else should be in the native library. With a modern embedded processor, the parsing and handling of each of these lines should be measurable in terms of microseconds, much less than the time spent within the library that actually does the work, and therefore should not be a bottleneck.
And I do put my money where my mouth is - everything that I wish to have a GUI nowadays, which isn't much, admittedly, I write in a scripting language. I always write it with crazy amounts of diagnostics and debugging, and on my slowest machine, so always get to test it at a relative snail's pace. If it's painfully slow in my scripting, rather than in the DB/GUI/OS I'm calling, I optimise what's slow, nothing else. But it pretty much never is, even at debug-mode snail's pace. (E.g. my dev website is a RasPi B+ with only 512MB RAM - external libraries/resources are >70% of my page serving time, many of them with latencies that can never be reduced, so there really is very little point in optimising anything in my code.)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves