Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Wednesday July 17 2019, @02:29PM   Printer-friendly
from the not-all-bad dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Touché) by The Mighty Buzzard on Wednesday July 17 2019, @03:19PM (18 children)

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Wednesday July 17 2019, @03:19PM (#868021) Homepage Journal

    When has adding javascript ever been the answer to improving the performance of anything?

    --
    My rights don't end where your fear begins.
    Starting Score:    1  point
    Moderation   +1  
       Touché=1, Total=1
    Extra 'Touché' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 3, Interesting) by sgleysti on Wednesday July 17 2019, @03:48PM (4 children)

    by sgleysti (56) Subscriber Badge on Wednesday July 17 2019, @03:48PM (#868036)

    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)

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Wednesday July 17 2019, @04:22PM (#868057) Homepage Journal

      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

        by Freeman (732) on Wednesday July 17 2019, @04:28PM (#868059) Journal

        My favorite part:

        The Graphical Editor lets you use Espruino even if you can't code!

        The optional graphical editor makes it quick and easy to create simple devices, even if you've never programmed before.

        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)

        by sgleysti (56) Subscriber Badge on Wednesday July 17 2019, @04:56PM (#868073)

        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 rigrig on Wednesday July 17 2019, @04:46PM

    by rigrig (5129) Subscriber Badge <soylentnews@tubul.net> on Wednesday July 17 2019, @04:46PM (#868069) Homepage

    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)

    by JNCF (4317) on Wednesday July 17 2019, @04:50PM (#868070) Journal

    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)

      by Pino P (4721) on Wednesday July 17 2019, @04:58PM (#868075) Journal

      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)

        by JNCF (4317) on Wednesday July 17 2019, @05:22PM (#868096) Journal

        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)

          by Pino P (4721) on Friday July 19 2019, @12:14AM (#868749) Journal

          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.

          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.

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

          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

            by JNCF (4317) on Friday July 19 2019, @12:47AM (#868759) Journal

            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

        by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Wednesday July 17 2019, @10:10PM (#868234) Homepage
        I'm a web-infested-with-JS hater. One of the haterest. I want my *webpages* to be webpages, renderings of an information resource, I don't want to be interacting with an "app". I'm also a low level coder, often C, and also in a realtime/embedded environment. So that's my background when approaching this topic.

        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)

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Wednesday July 17 2019, @06:55PM (#868155) Homepage Journal

      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)

        by JNCF (4317) on Wednesday July 17 2019, @07:50PM (#868182) Journal

        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

            by JNCF (4317) on Thursday July 18 2019, @12:52PM (#868471) Journal

            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)

    by DannyB (5839) Subscriber Badge on Wednesday July 17 2019, @05:11PM (#868086) Journal

    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.

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.