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: 2) by JNCF on Wednesday July 17 2019, @05:22PM (2 children)
I don't see why. Any arguments to be made for a website (running on practically any platform, choice of user agent with all the added accessibility that brings, etc.) still apply. With a defered script load and isomorphic rendering/rehydration you can sacrifice none of this, have the same initial render time, continue functioning in browsers without JS via plain html fallbacks, and still increase the efficiency of subsequent page loads when sufficient JS is available (since the whole page doesn't have to load). This can improve subsequent page loads on totally static content, like a series of blog posts. Should I really deploy a blog as a native app? Why? Should I not make a blog more efficient with JS? Why? (The only good answer I see to this last question is developer time, and admittedly that is sometimes a good enough reason.)
(Score: 2) by Pino P on Friday July 19 2019, @12:14AM (1 child)
In "(since the whole page doesn't have to load)", by "the whole page", do you mean the whole HTML document alone or the whole HTML document with all of its subresources? Because in the latter case, the subresources that can be cached will be cached.
You can spend developer time making it efficient with JS and doing nothing for the no-JS case, or you can spend time making the no-JS case as efficient as you can and having it end up reasonably efficient for all. Optimizing the no-JS case also helps avoid relying on a well that the adtech industry has been poisoning since day one of AJAX.
(Score: 2) by JNCF on Friday July 19 2019, @12:47AM
Without JS the whole document has to be requested, as opposed to, say, the blog post text but not the blogroll and related sidebar bullshit that doesn't change between posts. This is a win, but a really minor one that hardly matters, and I doubt I'd bother arguing this point if that were the only win. More importantly, the whole page (including subresources such as images) has to be rendered again regardless of if it was previously cached. Render time is the really big win here.
Note that I've been advocating basic html fallbacks, which means (among other things) that a user can turn on NoScript and not have any core functionality break. Ads have nothing to do with this.