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, Touché) by The Mighty Buzzard on Wednesday July 17 2019, @03:19PM (18 children)
When has adding javascript ever been the answer to improving the performance of anything?
My rights don't end where your fear begins.
(Score: 3, Interesting) by sgleysti on Wednesday July 17 2019, @03:48PM (4 children)
I'll just leave this here https://www.espruino.com/ [espruino.com].
(Full disclosure: I prefer to code in assembler.)
(Score: 2) by The Mighty Buzzard on Wednesday July 17 2019, @04:22PM (3 children)
That's just sick and wrong.
My rights don't end where your fear begins.
(Score: 2) by Freeman on Wednesday July 17 2019, @04:28PM
My favorite part:
It's like someone saw people using Scratch to teach kids how to program / logic and said, wow what a great idea! Then, proceeded to smash that into a product.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by sgleysti on Wednesday July 17 2019, @04:56PM (1 child)
What? You don't want a 3D-Printed Maker DIY JavascriptEverywhere™ Internet Of Things device?
My friend, you need a thneed. A thneed is a thing that everyone needs :)
(Score: 2) by The Mighty Buzzard on Wednesday July 17 2019, @06:53PM
Not until they port systemd to it.
My rights don't end where your fear begins.
(Score: 2) by rigrig on Wednesday July 17 2019, @04:46PM
This isn't for adding Javascript, this is for delaying the inevitable rewrite after you've already added Javascript.
No one remembers the singer.
(Score: 2) by JNCF on Wednesday July 17 2019, @04:50PM (9 children)
As long as replacing a single element has been faster than doing a full webpage request and render.
(Score: 2) by Pino P on Wednesday July 17 2019, @04:58PM (4 children)
I think the JS haters' point is that once you want to "replac[e] a single element" instead of performing a navigation, you probably want to write a native desktop or mobile application anyway.
(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.
(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
(Score: 2) by The Mighty Buzzard on Wednesday July 17 2019, @06:55PM (3 children)
So, pretty much never then? Reloading a single element is good for convenience but the overhead of being able to do so means you lose more than you will ever gain right off the bat.
My rights don't end where your fear begins.
(Score: 2) by JNCF on Wednesday July 17 2019, @07:50PM (2 children)
Pretty much always, assuming spherical cows and arbitrary developer time (there are weird exceptions, like iframe content that refuses to run after first render for security reasons thus requiring a full page load anyway). Defer the script, no overhead until after the initial render. Provide basic html fallbacks so everything works the old slow way before the script is finished and the fancyshmancy element swapping is ready.
(Score: 2) by The Mighty Buzzard on Thursday July 18 2019, @11:23AM (1 child)
You can't defer script loading of core site functionality and achieve anything useful. There's a very good reason we're so much faster and more responsive than say a similar green site that's in love with javascript.
My rights don't end where your fear begins.
(Score: 2) by JNCF on Thursday July 18 2019, @12:52PM
With basic html fallbacks, yes you can. Deliver basic-bitch links with unique id attributes, then have the JS replace them with elements that have click events triggering element swaps instead. Forms are only slightly more complicated, totally doable. The Green Site isn't doing isomorphic rendering and rehydration with defered script loading and basic html fallbacks, and I never claimed their use of JS is clever. JS can be a huge win for user experience if used cleverly and tactfully, but it rarely is. It's a developer time/education issue, I'm betting there are some polished frameworks making this behavior easy by the end of next decade. In the meantime it's a mess to set up, but the end results are glorious.
(Score: 2) by DannyB on Wednesday July 17 2019, @05:11PM (1 child)
This is used if your mobile app is already infected with JavaScript. This is introducing a new C based JavaScript interpreter to give you a 2 second faster startup time.
Each app that uses it has its own copy, rather than somehow centralizing this (supposedly) improved engine. But of course, modern smartphones have gigabytes of memory now.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by The Mighty Buzzard on Wednesday July 17 2019, @06:57PM
Oh, well that's better than the alternative, I guess. I withdraw my objection with reservations that a slight speedup will make more people consider it a viable option.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday July 17 2019, @04:11PM (1 child)
it's a trap!
(Score: 2) by DannyB on Wednesday July 17 2019, @05:12PM
The Facebook
Is Your Friend
Trust The Facebook
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: -1, Offtopic) by jmichaelhudsondotnet on Wednesday July 17 2019, @07:21PM (2 children)
to start a campaign for the arrest of Mark Zuckerberg for espionage.
His obvious contribution to spying to he detriment of American society is traitorous and obvious. He has violated the privacy rights of evey american and faciltated all manner of spying on every one of its users, as well as criminally incompetent security. And that strange symbol on his hoodie, which should freak anyone out.
I would say he also facilitated spying on the american military, but tax dollars are paying for a dozen members of every armed service branch and 100 law enforcement agencies to read this and sit on facebook 12 hours a day intentionally angering and confusing the citizens of the country they are supposed to be defending.
You know who you are, pat yourselves on the back for "defending" the children and constitution and assign someone to write a carefully psychologically calculated troll response that distracts from all my points and calls my sanity into question.
It is truly hilarious how police and military trolling forums and infiltrating civilian society as defending the country. The defnition of the word 'soldier' and 'defense' has gotten to the point of true absurdiity.
So, charge Zuckerberg with what they charged Assange with, but x100000000...000? Who's with me?
And who's that following me?
(Score: 0) by Anonymous Coward on Wednesday July 17 2019, @07:41PM
Nobody is following you.
(Score: 0) by Anonymous Coward on Thursday July 18 2019, @04:14AM
Impeccable.
(Score: 0) by Anonymous Coward on Thursday July 18 2019, @03:34PM