React Native 0.64 With Hermes for iOS
Subtitles
Show
[Music] hello everybody and welcome to the next react native show episode and today we are here to talk about something very special which is hermes a js engine made specifically for react native and today we are going to talk about it and the recent feature of react native 064 which is hermes support on ios today with me there are two very special guests shin that works at facebook on the hermes team and alloy that works at microsoft so these guys been working together with me on the hermes um making it possible to bring hermes to ios and to maccas which we'll talk about later in a second but before we do it how about you guys introduce yourself to our listeners and the ones that are watching us on youtube just in couple of words so i'm eloy duran based out of amsterdam the netherlands from my house boat that you don't get to see any lovely video feed from working remotely for microsoft um have been doing that now for a year joined to work on react native in office but i have since then moved on to a different team so my knowledge is already getting a bit rusty but i always love to chat and be around go for it sean yeah hey what's up guys um my name is shun i'm also using the handle at hux pro on the internet so i'm a software engineer at facebook working on hermes javascript engine um friendly speaking this is also a very new experience to me i was a funded engineer and writing some javascript stuff so my day-to-day work in a nutshell is implementing and releasing new javascript features to both internal and external react native community so i helped with
managing hermes open source releases and that's how i get to know mike and alloy and to be able to speak here today yeah that's about nice that's that's very exciting i guess sharon we have a very similar background because i also started as a frat and engineer and uh that was also my very first experience with jeremy's um by doing this pr actually i guess aloe was uh kind of having the most experience uh from all of us actually if it wasn't for his help on the uh you know um silang and all these build systems then i would probably pretty last um which is not a surprise because he's been also working on cockapods before right are you up you want me to cover that well i guess you know it's it's it's a pretty interesting contribution i guess i mean it's not even a contribution because you're actually co-author of it so i guess that's pretty um i would say impressive yeah yeah i did indeed start the project here on this very houseboat um but uh and so i guess most more relevant yeah is that i come from the uh the apple ecosystem um and that's so that's why you know i ended up working on ios and mac os related technologies and i've always been interested in crossing you know crossing languages so i didn't do just objective c at the time i was interested very much in at the time in ruby and so i worked on the various ruby objective-c runtime bridge technologies um and thus it was easy for me to try out react native in 2016 in our production application so guys cool that's that's been a while already but you know uh that kind of
proves the point that you know react native is the place where we from different communities can actually meet and collaborate all together from native and from the front end so that's pretty exciting um okay cool so uh now that we know a little bit more about our guests i guess we can move into the main topic of today's podcast which is hermes and i guess it would be a great thing to do at the beginning which is doing a little introduction to what harem is actually is and for those who haven't heard about it what would be its biggest selling point um and i guess sean maybe you want to start as you are actually the representative of the hermes team at facebook yeah so hermes basically is a new javascript engine built by facebook it's designed for the mobile environment specifically to improve the performance of reg native apps but as rig native currently expanding to desktop thanks to microsoft we've seen some of the key benefits are also very transferable to the desktop as well um so for selling points maybe we should pull off the deck let's do it so hermes can help with three primary metrics to improve the user experience so the first one is tdi or time to interactive which is basically how fast your app can start up this is the most noticeable one to the end users the second one is application size or binary size this is comparing to the jsc that can the current default engine of the reg native on android and the third one is the memory footprint or memory consumption so this metrics are critical to model
since the computation and memory resources are much more constrained there because of the form factor and the thermal limits but they are also very helpful to desktop as well so we have some data collected from facebook so we so as we can see the time to interactive is cut to half and the apk size is roughly cut to half as well and we're also able to cut memory by about one third to one fourth let me show you guys uh classic videos so this is open source app and the left one is the recognitive with hermes and the right one is regulated without hermes and you can see the left one uh start much faster than the right one cool so sean thanks for you know showing this deck it really worked quite it really worked great and now uh you know we've seen that you know uh hermes is faster than jsc on android and that's quite impressive um but jsc is not the only engine on android i mean you can actually run v8 or i know that at least historically react native windows i guess used to be running chakra i remember some interesting comments about that so i guess um did you try any benchmarking against the other engines rather than just jsc and if yes what were the results i don't we don't try that internally but i've seen a hacking news that some employee from microsoft office has compared hermes versus va and chakra and actually they already using baiko for va and chakra which is already a little bit more advanced than majority of reg native users and still observe some tti memory and app size wings i think qrs users can check out that hacking news
and i can attest that that person is not just a random person that person andrew really takes his stuff serious so if he says that then he did some serious benchmarking oh that was andrew nice i know him yeah awesome ah that's great so so just to recap the results were i guess showing that hermes is faster right yeah um otherwise we wouldn't be bringing that up right cool so i guess you know it really makes me wonder like how is this possible what is the the magic behind hermes that makes such big improvements possible yeah i think the short answer is that the magic behind all this is what's so called by code pre-compilation which means hermes can compile your javascript source code to optimize by code ahead of that time so your recognitive app will adjust the ship with this buy code and hermes can start execution directly from there um we can go into more details later yeah and actually it just happens that uh later means now actually because that was what i was going to ask you about so it's quite funny but it's all right uh i mean actually uh jokes aside i i'm really curious about it actually you know um like my knowledge and i'm coming from the um front-end developer uh like front-end development was pretty limited about engines actually the first time i've learned about the engine and and compilers was when uh there was a um a uh this github project by james kyle which was like a very tiny compiler and and and that's when i've learned you know about these things so i guess our readers my listeners might be getting quite
confused right now what aot and jib mean and and what's the difference so i guess we can just briefly talk about what does it actually mean in practice that herb uses aot yeah i think first i want to expand a little bit on the meaning of aot versus jit here so i've seen people exclusively regard aot as compiling some program usually written in c or c plus plus to native machine code and mistakenly thought hermes is compiling your javascript to native code as well this may or may not because the that's what wikipedia was saying i actually edit the wikipedia entry of ahead of time compilation weeks ago to make it a little bit more generalized so my take on aot or jit is more valid timing when a compilation and usually the compiler optimization coming with it is performed no matter what exactly the source language or the object languages so for instance in the javascript community we have angular using the word aot for converting its html template and typescript to javascript and the jvm language closure i also use the word aot for pre-compile enclosure code to jvm by code to help with faster startup etc so in my point of view ahead of time aot and it's not really like necessarily opposed to each other we can see java as always com pre-compiling to biker ahead of time and the jvm may or may not jit that bico it can just interpret it there was no jit back to jdk 1.
0 or there could be a jvm like hotspot that can jit compiling the buy code down to machine code to accelerate execution so hermes is basically the same as
0 or there could be a jvm like hotspot that can jit compiling the buy code down to machine code to accelerate execution so hermes is basically the same as
java in this regard so technically there is nothing stopping hermes from adding a jit but we actually experimented with one but we couldn't justify value comparing this overhead so we recently just deleted uh so what does this mean in practice in practice it simply means we're moving as much javascript engine work as possible to the built in of your reg native apps all your javascript source code will be pre-compiled to hermes bico after going through many typical compiler optimizations such as in-lining deco illumination loop environs etc at the view time and when you open your app it will be directly executed from there and from such optimized buy code and that's where some of the performance benefits came from um i think in addition what words to mention is that recognitive across all platform had made this process really simple for react native app developers you just need to flip a switch to enable hermes and that's usually about it um besides android ios and mac os i also heard about recognitive on windows 0.
64 had made herms uploading much easier nice all right maybe just yeah yeah maybe just i think of course maybe for for your for some for some readers that you were referring to are listeners i guess and viewers yeah actually hello hello all of you um i think maybe like so aot literally just means ahead of time right and jit literally just means just in time so in in and of itself it doesn't imply what it is doing it's just about when you do it right so indeed and when like the simplest optimization that can be seen here with hermes when it comes to the bytecode
64 had made herms uploading much easier nice all right maybe just yeah yeah maybe just i think of course maybe for for your for some for some readers that you were referring to are listeners i guess and viewers yeah actually hello hello all of you um i think maybe like so aot literally just means ahead of time right and jit literally just means just in time so in in and of itself it doesn't imply what it is doing it's just about when you do it right so indeed and when like the simplest optimization that can be seen here with hermes when it comes to the bytecode
aspect is ahead of time compilation means the browser or the sorry the javascript engine will not be parsing any javascript code and doing some sort of uh you know compilation thereof that is already done ahead of time right so um so yes good point sean i think a lot of people will easily think that this means something about native like it implies something is really just about when you do the work and then the work that you do can be different things right yeah and i have to say that i really love this explanation because i guess uh before this podcast my aot and jet explanations were usually related to the native code and now the timing itself makes it really easy like even with the css and js libraries you could say that most of them are jet they must have the runtime and there are libraries that don't have runtime because they transpile everything to pure css ahead of time so you know instantly it makes your library fancy because you can say it's aop but you know jokes aside it is actually quite quite a uh simple answer uh to to the difference so i guess uh you know this this is worth highlighting um at this point very good awesome so i guess you know uh continuing this explanation that means you know in practice it means that certain steps with hermes on the react native uh certain steps are happening ahead of time rather than just in time and um if we would break down like all the steps in the pipeline that happened when you run react native app uh what what steps exactly are you know happening ahead of time
and what what is the rest that is still happening just in time yeah luckily we also have a deck for that nice so as you can see from this from the dac we have the built-in on the left which is what happened on our machine as developer and also we have runtime on the right which is what happened on the user device which is usually much less powerful than developers machine so as for all the modern javascript engine basically the entire compilation is happened just in time it just in time compile javascript to buy code then just entire compile the buy code to machine code so the first step will be lexing and parsing so we're trying to parse your source code and find all symbols and functions there and compile to some unoptimized by code i recommend reading or watching the cost of javascript talk or articles from my friends andy osmond from google chrome to understand the parts plus compile can take 30 30 percent of the total time spent on javascript during a page load and hermes can get rid of this 30 so and then this javascript engine would execute a bicode by execute i mean interpolate so all modern javascript engine like va jsc spider monkey chakra has an interpreter before layer jute and then during the interpretation some of the function might be called say 10 times then the base logic is kicked in to compile the unoptimized bytecode to unoptimize the machine code which would be three to five times faster but the generated code is really
huge and that's why va wants to replace their base jit the food cogen to ignition to reduce memory usage and then when a function is called 100 or a thousand times and considered super hot the optimizing jit were kicking and compiled to really compile the unoptimized machine code to some really fast optimized code in reality there might be multiple tiers of such optimizing jit so this code are really optimized because they made assumption in terms of speculative optimization so there is always risk that the assumption is broken by the dynamic natural of javascript hence the engine has to fall back to the unoptimized code this is termed the optimization so pay attention to how many variants of copies of your code need to be stored in memory and how many times your code needs to be compiled compilation is usually super expensive they take a lot of cpu cycles and tons of members to do the work so that's the current typical modern javascript engine pipeline and for hermes hermes tried to move all the heavy work to the building on your powerful developer machine and reduce work on the user device so we will compile your source in the developer machine so there is no need for minification and we will generate an intermediate representation called ssa or static single assignment not social security administration and optimize and optimize that ir to some optimized form of the ir so the key is that we have all the cpu and memory resource to do heavy optimization
in your machine and it's okay to take longer here but for jit engine they usually have to do that optimization relatively quick since its own user device and the code has to be executed there just in time so we will generate a optimized by code bundle in the build type and we will ship that by code to the user device so in the runtime it would be really cheap to just load the buy code it's same as how um a native executable is memory mapped to to the memory and execute it so there is no jute this doesn't mean hermes can have one as we mentioned before it's a deliberate choice that we made for our recognitive workflow yeah thanks for this explanation i really love the uh all the different smaller pieces that you have broken down i guess that really helps to understand the pipeline and now you know i i do wonder why like maybe not what is specific about react native apps that made hermes possible but generally speaking i would assume that uh like after seeing all of this and after hearing all of this it is like quite obvious to me that aot engine is the way to go but on the other hand we still do have like most modern engines such as v8 and jsc uh jit and now the question is why i mean um why is that and what is what is it so different about react native apps that you know would make a good use case for aot then yeah um this is actually a really hard question um so i would try to cover that um i believe a historical context like in the first place was that tdi is really critical to the success of recognitive apps or
actual facebook usage of that so there was a talk by eli white on in the facebook a fa developer conference session talking about the marketplace tab of the facebook app which is entirely in recognitive um and the issue was that it's uncomfortably slow to load it and and and see the first content and being able to interactive on a low end device i forgot the exact number but i remember super slow uh so that was the major point that facebook wanted to solve so i guess people kind of realized the overhead of js compilation is huge during the initialization and people also realize oh recognitive is very different say how the code is distributed to the app is then comparing to delete distributed javascript code to web browser so i think the first difference is the environmental difference or the how or how the code is delivered um so in rec native app usually javascript code is bonded within the app and also we have more control of the runtime environment um so so i guess that's why by code pro compilation makes sense because you can't really ship by code to browser there are different kind of browser using different kind of javascript engine and they use different kind of bi-codes you can just you can't standardize that there is a proposal called binary ast and it's trying to standardize how asc can be delivered and and help with faster startup but it's it's still far from being able to ship by code directly i believe the second major difference would be the workload um so different javascript application have very different patterns
so javascript running on web browsers are super diverse so the engine has to be tuned to be very general purpose uh the javascript engine in the browser tend to have multiple tiers of jit to be able to accommodate that and javascript running on node.
js however are usually very server-like their lifetime tend to be longer and they tend to do very repetitive work uh so and also they need tend to be running in a very beefy machine right so this is an ideal scenario for super highly optimized jit you pay the heavy warm up cost once and then you'll just stay with super fast code in the rest of the lifetime but javascript running rack native apps in contrast are usually more affirmative infirmary um and that's repetitive so during the lifetime of users interacting with your recognitive apps it's more likely that the user will click different buttons and a file very different event handlers so we did some static degree analysis and realized most the function in recognitive during the startup times are executed between zero or one time and even after startup it won't be like a heavy number crunching sort of workload but more like a periodically reacting to user interaction so legit doesn't improve the responsiveness there as well there is also memory concerned as being like usually recognitive apps or mobile apps i've seen people suggesting that for such memory constraint environment even you are using a jit capable engine you might want to turn off its
js however are usually very server-like their lifetime tend to be longer and they tend to do very repetitive work uh so and also they need tend to be running in a very beefy machine right so this is an ideal scenario for super highly optimized jit you pay the heavy warm up cost once and then you'll just stay with super fast code in the rest of the lifetime but javascript running rack native apps in contrast are usually more affirmative infirmary um and that's repetitive so during the lifetime of users interacting with your recognitive apps it's more likely that the user will click different buttons and a file very different event handlers so we did some static degree analysis and realized most the function in recognitive during the startup times are executed between zero or one time and even after startup it won't be like a heavy number crunching sort of workload but more like a periodically reacting to user interaction so legit doesn't improve the responsiveness there as well there is also memory concerned as being like usually recognitive apps or mobile apps i've seen people suggesting that for such memory constraint environment even you are using a jit capable engine you might want to turn off its
jit i i don't have the food contacts but i believe the recognitive apps on javascript c javascript core also doesn't do jit usually yeah and that's actually the thing that we will really get to later because it's not going to be the next question and uh and once again thanks for this uh very deep explanation i'm really interested about this um um this this standard for you know shipping byte code i guess you know on the web that could be pretty exciting so um you know thanks for bringing that up and i guess you know um that brings me to the next question which is you know like listening to all of these it seems to and actually you know hermes has been running on android for quite some time already um and so one would assume that you know it's pretty much complete i guess uh but you know uh like i i'm just curious like what's the roadmap here yeah i think we can start from the roadmap um i guess we are far from being completed i think one thing that people notice is that uh admittedly herm is a little behind of the javascript standard um and also tc39 release features every year so like completing all javascript feature would be always a moving target um so it's definitely on our plan to com support more and modern javascript features um but also we want to implement those features in a way that won't regress there was a reason hacking news about using led cons in jsc was three times slower than using var so we don't want that cons like that so we're also only so we usually only
launch a feature when it's proved to be not request anything or have some improvement there are also features in javascript that are more important to recognitive than else the current promise in rec native is polyfilled with set immediate so promise is scheduled as a priority of timer but not micro tests this is true regardless what javascript engine you're using we're working on improving this since it's required to enable react concurrent mode for recognitive so that's javascript feature coverage the second major focus of hermes is always performance so we're working on some of some significant improvements to our garbage collector so gc is something that you can tune you can tune the space of young generation you can tune when to perform a major gc depending on the occupants and fragmentation ratio so in a more advanced gc you can tune how long do you want to pause or it also not stop the world so we want to keep the pause time reasonably short this would directly benefit the reg native's new architecture because now we have synchronous call into javascript we're also working on reducing even more memory footprint so one of them is called hermes value32 currently all javascript values are represented as tagged value which is 64 bits so it can represent pointer on 64-bits architecture but we're working on a 32-bit version of that with pointer compression another one is small array optimization we kind of observed that most of the arrays in react
app are usually more like a tuple because of the react hooks you you always get a tuple destructure from the set state you stay use reducer that kind of hooks right so we can specialize those kind of small array to use in light storage without actual storage allocation so the third point is tooling we're constantly improving the vertical integration with react native tooling ecosystem such as debugger profiling source map that kind of thing there's currently an unstable transform profile for hermes in the metro bundler where you can drop half of the babel transform to speed up the boundary so working on removing more babel transform and stabilize that profile there are also many other exploration items that need to be proved to be good but in general i think we are tuned for the practice from react native community this gave us some focus and some freedom that other general purpose javascript engine can do last but not least we will always have feature requests from the open source community of course from um from microsoft's perspective um in our partnership with facebook one um big hurdle to making the switch right for react native to use hermes by default was um being able to support native apis that are really important and one the one that that we partnered on is the native internationalization apis so the intel spec because as i understand it but i might be wrong or it's outdated facebook itself doesn't use the native
api yet it is considered a requirement uh for the community before we can make that uh switch which seems like the the responsible you know choice to make we obviously should not uh make it harder for people to do the right thing when it comes to internationalization what i know from that is that microsoft has contributed to hermes the android part of that that's completed for react native windows uh while that while react native windows and macos currently are not a requirement for to to decide what gets enabled by default you know in upstream react native uh there is the aspiration to be in sync and so react native windows currently does have an implementation of the intel apis but it relies on something called icu which you know it's just like let's just say it's like a a globally uh used uh api to power internationalization so it comes from the unicode consortium if i recall correctly uh but not all platforms provided and you know it has a lot of metadata so it's that's something that you want to ship with the with the application um and so i don't think all windows platforms provide icu or at least not in a way that you that any application can use it and so the current effort was to port that work to use the sanctioned what is it called windows globalization apis and actually the same thing was on my plate to do for mac os before i transitioned to teams i can't say what the state of it is right now but the issue is pretty much the same mac os
and ios both rely on icu to do that work but one of them only one of them provides a little bit of the api to applications otherwise it is on it's considered private and so it's also unfortunate that we can't do a straight port of the existing android work which uses icu directly to these other platforms uh they have to be you know transpiled i guess in a sense to not use icu but use the sanctioned api switch on windows is the globalization apis and on macos and ios is the just the core foundation apis that allow for some internationalization so it is interesting you know how facebook doesn't even actually use those apis but it is considered essential to the community right as always we always have to balance uh what is the right thing to do for the community like what is our vision of how what type of applications react native delivers um and this is just a responsible thing to do yeah that actually makes me wonder what is it that facebook is doing internally if they are not using the intel apis uh probably something custom right i hear that i have a few more engineers than the average application developer so you know yeah yeah well that's that's that's right uh but it's it's great to hear that you know there is an effort to make that uh work for the community i guess that's really great that you know you're still keeping that perspective in mind is there any place where one can track the progress of this like a github issue umbrella issue or a project or something like that we can link later in the podcast that's a great question i i let me find some i think i'm all the work that we in our partnership
agree on taking on is should be public so i'll find the link and we can link it okay cool yeah we can uh we can include it later in the uh description notes so um if you are listening to this part uh you can check the description that's where it should be so definitely upload for microsoft uh the intel work from microsoft so hermes has been really great for us at facebook um so as eloi mentioned there have been a few blocker that kept the community from being able to adopt it notably proxy and intel each had over like 100 thumb ups on the feature requesting issue uh so for the proxy we recently make it default and release with the reg native 0.
64 and that actually a feature facebook doesn't use in internally as well so it's built entirely entirely for the open source community and the intel works thanks for sex for microsoft the android intel support is very close to completion um we the plan is to release intel with recognitive 0.
65 for android so stay tuned for that uh as for what facebook use internally for internet internal rationalization we use fbt which is also recently open source so so the intel api is also for the community i kind of would like to do another podcast on fbt because i just googled it in any time when you said it and uh it's it's quite interesting um you know approach like like it's it's always an interesting um you know like concept when i see you know facebook having their own uh implementations of things that we would say are obvious and are
64 and that actually a feature facebook doesn't use in internally as well so it's built entirely entirely for the open source community and the intel works thanks for sex for microsoft the android intel support is very close to completion um we the plan is to release intel with recognitive 0.
65 for android so stay tuned for that uh as for what facebook use internally for internet internal rationalization we use fbt which is also recently open source so so the intel api is also for the community i kind of would like to do another podcast on fbt because i just googled it in any time when you said it and uh it's it's quite interesting um you know approach like like it's it's always an interesting um you know like concept when i see you know facebook having their own uh implementations of things that we would say are obvious and are
you know sort of publicly assumed to be the go-to choices and still the facebook scale sometimes leverages you know basic problems and shortcomings that at your scale just don't work and so that's why it's always you know great to have uh sort of um deep dive into you know reasonings behind these so uh definitely going to write down down for the for the next podcast but i guess we can wrap up the first part and quickly move to the second part which is uh not about the hermes history and and the hermes state and android i guess we have covered that pretty um pretty deeply now i wanted to talk about you know something that is very exciting and very new as of react native 0.
64 or something that has been released recently which is hermes uh support for ios and something that releases a part of react native 0.
64 but as a part of react native mac os which is hermes support for react native macos and i guess because i was involved in working on that and i know that my work on ios um wasn't the beginning it was actually mac os where it all started i guess allo it would be great um if we started with a bit more context on like the democrats work like like i have to say that i'm really impressed uh that microsoft has been investing in react native so much and that is you know supporting desktop mac os platform as well even though it's not you know their sort of environment it's windows of course but it's really great and so i'm just like curious about like uh the maka's support for hermes what's going on there and why it's hermes and not chakra for example and and how that relates to react native
64 or something that has been released recently which is hermes uh support for ios and something that releases a part of react native 0.
64 but as a part of react native mac os which is hermes support for react native macos and i guess because i was involved in working on that and i know that my work on ios um wasn't the beginning it was actually mac os where it all started i guess allo it would be great um if we started with a bit more context on like the democrats work like like i have to say that i'm really impressed uh that microsoft has been investing in react native so much and that is you know supporting desktop mac os platform as well even though it's not you know their sort of environment it's windows of course but it's really great and so i'm just like curious about like uh the maka's support for hermes what's going on there and why it's hermes and not chakra for example and and how that relates to react native
windows are you planning to bring hermes there as well that is a lot of questions mike yes i know i'm sorry like i've been waiting to this part to ask you all of these questions i just couldn't control myself gonna stop myself from like asking five of them at a time well we can start with the uh background on like hermes and macos how is how it all started and why hermes and not chakra let's say yeah well i think you know i think actually it probably answers a few of your questions in one go um so yeah so let's see so let's back up so microsoft uses react native in office right um and it uses it to i mean look office itself is not written in react native that would be that would be silly from the perspective not that javascript is silly but it's like office is a code base that has existed long before the humans roamed the earth right it's like this it's such a large code base it exists react native is mostly being used right now to deliver what they call experiences so you know small pieces of widgets like integrations into the larger applications and we want to allow partners to build these widgets without needing to think about the large matrix of like where's office deployed to what different ways do you need to compile it um or even have access to all of those you know apis that that will be needed for that so having like a being able to use javascript for that is a very powerful way to do so which obviously has been done many times before also in office in the form of you know a
web view just just put a web view on the screen and allow somebody to write some javascript and html but i think i think for the listeners to your podcast it's already pretty clear why you would choose react native over something that is basically just a webview so we don't need to go into that that's the same you know that's the same case here um so so that is definitely like already a requirement that's why microsoft not the only reason but that's why office is you know invested in making sure in using react native but react native obviously is a um an open source project in a sense at least so far that the things that we need might not align all the time or are not needed all the time by for instance facebook like you know like we just discussed with the intel apis etc and so if we want to have a stable environment we need to contribute to that uh right and so um that is why we invest in it and also not just in the only in the things that we need but as a platform right and we want to unlock people to to write um applications more easily not just for ios and android but in the same way for mac os and windows right um so that's that's that's all sorts of good business reasons to uh allow to help flourish a otherwise uh open source uh project that is in many cases run by a lot of people in their spare time right um and so so clearly microsoft has already looked into prior to hermes into other solutions like we also saw from the links to hacker news article
but you know chakra itself is is on its way out in microsoft just entirely so there would be no point in in then resurrecting that for mac os um [Music] so v8 would be you know an an interesting alternative and i i know that there has been a lot of testing i don't know in how far it has actually been rolled out but you know it then it comes down to trade-offs and when we are talking about trade-offs you know settling on a single engine that is shared is hermes does not necessarily always address all the same uh optimizations on each platform but there's something to be said for having a a single uh engine that is um malleable and and targeted to this environment right so we can have rather than rather than spending hours of microsoft engineering time and i can tell you there have been many hours in trying to get you know debugging to work with edge chrome vs code to various to javascript core to v8 you know that is time that we could better spend on making flipper even better right um and and and we have that time because first of all hermes is entirely accessible to us if we need to hermes to act a little bit different for this case then we can do that right um and that is actually a thing with um uh remind me the names all the names the native more synchronous access to native modules um is it fabric module two modules yeah no i think yeah maybe i mean it's all intertwined right so i think one of the issues no
definitely uh turbo modules and i thought that was some intersection with fabric as well uh but um you know there is some cases if i recall correctly where you want we want the users to be and the users are the the react native developers here right to be able to debug their javascript but that javascript might then go into an asynchronous like a blocking native call and that is not something that the typical uh chrome debugger protocol uh expects that's because that's not a thing that those the the engine does in the same way and so uh with hermes um it is it is feasible to have this implementation of the protocol that tree that allows for the for that type of stuff right so we have very specific needs in react native and having then access to a javascript engine that allows us to target these specific needs means that it is it's going to make the overall experience better and we can standardize it in a single place rather than trying to patch it onto all these different places right which is actually kind of like very much how i at least like to react native over ui kits and apkid development because if you if you if you have an issue you can actually go in and fix it uh rather than patching around it so so i guess that so that answers why we you know why for microsoft we would go with hermes rather than another engine so there's many there's multiple reasons there right um yeah because um in some cases like like you mentioned like the ap something like the ap apk reduction is something that applies very much to
android and shipping like a jsc that is good for react native that is not something that necessarily applies to ios or macos right like we have good jses but as with many thing in engineering it all boils down to the the sum of all things and that you need to make those trade-off decisions and so up seeing choosing a single one allows us to be to have a much better developer story for much better uh place where we can optimize things in the long run so that's kind of what it what it boils down to a lot of them which is great and now i actually have so many follow-up questions to you but i'll just stick with the latest one um you mentioned that you know like like the bundle like the apk size optimization while being an improvement on android is not necessarily a uh improvement on ios and mac os which is quite obvious uh because jsc kind of comes with the platform so i guess uh the question would be like what would be the selling point on ios like for android everybody knew that you know there were some issues but like i always felt like ios was the um faster platform more stable platform and i guess generally apple ecosystem so i guess uh what would be the selling point for ios rather than just having the unified engine that you obviously mentioned before well i want to be clear first that the apk size is an issue now uh shun can probably better speak to the road map but there's inherently nothing stopping the hermes developers from making so many optimizations to the byte code that it reduces the overall code size there you go
um so it's not necessarily the case right now that is the case and last time i measured at least right um so given that right now that that's that's not necessarily a choice to get well look um i think a lot of people that have also experience with server development right that's the trade-off there is like will we spend a lot of engineering hours on making this code very optimal or can we just buy a few more servers right so sometimes you need to make decisions that are that seem a little uh unintuitive and in the k in this case uh yeah the initial download might be a little larger but if your tti goes down uh that's you know that that might look the the download time that a user pays and look i i am no expert in this right that's probably people that have looked into this data a lot but the downloads time it takes and increases is a one-time cost whereas the application launching hopefully is not a one-time cost right uh hopefully they love your application and they will launch in times and so uh if you're into user experience and whatnot you know that's the perceived performance over actual performance and sometimes something that feels better is just better for the overall uh expectation which i don't think in this case actually applies in tti is actually faster and that is the goal right we do skip things like parsing etc things that just aren't aren't necessary in a controlled environment where you know the javascript that you ship etc so those are the types of things that i think would matter more i think in terms of right now
but don't pin me to this this might be something that sean knows better uh you know that's that's things like um intrinsically because of how the byte code is loaded from a single file you they're they're they're they're uh the memory is it's not loaded entirely into memory it is memory mapped and so it the the uh the os can better uh move around memory it can like take parts of them it can take parts of the of the code out of memory when it's needed uh without the application needing to allow for that which uh apparently is something that is harder with uh traditional um uh engines um so you know that's there's there's various different reasons why one would choose for it and there's also it also depends on the audience right in our case yeah people making and maintaining things it's definitely standardizing on a single thing makes a lot of sense for users your initial tti might be what you care for look if you don't care for that if you really care about optimizing for apk size right now in ios then we should just be clear about that right you should use jse hermes can potentially still have perf advantage on tdi from the bicycle pre-compilation those advantages but also for memory uh so mind map as eloy mentioned has basically two advantages for sino the first one is like say you have multiple javascript module which will be compiled to different biker module then that is something that you can lazy loaded each module into the memory whenever it's actually used um when operating system paging those uh buy code module and the second one is that we can easily return back memory
uh back to the os and that's really cheap there is also um vertical integration that hermes can possibly do like if you if you donate function name we can strip function them and also we have some static building optimization or string duplication that is very kind of specialized to recognitive usage um the second advantage in general would be the having a consistent vm across all recognitive uh platforms that allow you to mention yeah like providing a consistent debugging experiences and having better uh tooling integrated with recognitive ecosystem yeah and and i guess that was my first uh first you know the first thing that came to my mind that you know having a unified engine certainly makes it easier for all of us to focus on you know delivering certain features and tooling uh instead of you know having separate developer tools for like each engine which are obviously different because for example the debugging experience is different with hermes and different with you know jsc for example which is one thing that i wanted to add on top of uh like um what you said before alloy um regarding the memory mapping there is actually a um and i'm gonna do a uh sort of humble track right now uh since we are working on a project called a react native webpack handler previously known as hull uh the name is to be verified because we just realized we are actually using two trademarks in the name which is you know kind of a legal challenge to handle right but um the point is that you know we are we do have this uh sort of uh we are working on the future based on module federation which lets you kind of
split your bundle into smaller um js files that you can dynamically load and that is kind of a evolution of the ram bundles that used to be supported for the jsc then i guess right now they are not working quite well and obviously with hermes and memory mapping there is no a clear uh sort of need for it and then for for kind of fixing it so i guess that's the direction we are moving uh cool so um i mean i just have like two more questions about you know hermes and ios and hermes in general and i guess you know something that has been you know asked ever since we started talking about hermes and ios from the very beginning was what apple is going to tell uh during the review process and i know this is the most favorite question that everybody is asking like uh like like what will apple say and obviously you know we know that uh hermes is iot so technically speaking everything should be fine um so i guess you know like i kind of just realized that i answered my questions already but um i wanted to check with you guys what you think about it like uh do you feel like the aot uh was the primary reason why apple like didn't accept traditional engines and and that is what makes it uh possible uh potentially in the future to build apps with hermes and ios and mac os i think this is uh interesting territory and i'm glad that you already have how you started it i like how you already answered the question i i look let me let me let me tell you a different story
once upon a time i worked [Music] on a startup in a startup [Music] that was called rubymotion and it was an extension of an open source project that i collaborated on um and it compiled ruby to native code um for ios and mac os that was you know mac ruby was for macos and so you know ruby is also dynamic and um thus the obvious choice would be a jit engine um but apple you know they they have had uh i don't know what the what the the wording on it is now but the they in the past at least there has been very clear wording about jit not being allowed and jit again is just words right it just means just in time so to be clear in this context it means compiling code to native code in memory and marking that memory as executable is not allowed and the reason to do so is uh is good because it adds a security risk um right and so so i get that um but i can say that you know with ruby motion we so we did not do jit we did entire aot compilation and that was fine so right so the the the point is mostly that we cannot we and this is purely again about the aspect of uh when people often think about the whole something jit something aot and apple right this is that's what this is about it is about compiling code to native code and marking it as executable in like in memory that is not allowed and that is not something that hermes does yeah now then there's there's lots and lots of other texts about javascript etc you know that's like a whole diff that's
where that's why it gets so confusing to people but when we talk about when people talk about the jit aspect it's very clear what that's about that's about this thing and the harems does not do that assuming that everything goes mostly and we do have you know hermes and ios uh available as a as a as a as an option that you can turn on in your pod file and we do have it on android in a similar fashion uh and and it starts being accessible and available in other platforms i guess eventually uh there there is a plan to make hermes the default it's probably still early stage to speculate about ios and other platforms but it makes me really happy to see you know all these improvements happening to ios android and react native in general like the architect re-architecture and all these pieces changing and improving in the experience performance that's uh that's really great um so i guess you know the last thing i wanted to talk about but i guess uh we are probably um yeah like we recorded so much material that you know it is going to be better if i do another humble brag again i'm um i'm i'm working on an article uh where i go through the details on how hermes was implemented on react native um for ios including you know various different pieces of the architecture that made it possible so if you are interested to learn more about how to turn it on uh how it is possible to make hermes compile on ios and mac os because i also link to the microsoft work and alloys work um go to the link to the article that is in the description as well that's where you will be able to learn more about the technicalities
and how hermes integrates with react native itself and i guess that brings us to the end of this podcast which has been really exciting and uh first of all i wanted to really thank you guys for joining uh and and i wanted to thank you for all the work that you did on hermes on macos ios 100 because that's been a tough and really challenging work and again i'm really happy that we are doing this today after rescheduling for quite some time so once again thank you very much and i i hope that you enjoyed it well it's it's truly really nice to meet you guys and chat about hermes and rick native especially in this quarantine theory um i'm i'm i'm glad i went through my first public speaking english it was a tough a little tough yeah that was your first time definitely my first public speaking english and first podcast i wouldn't tell like it felt like it felt like like you did it like a pro so and i'm not kidding like should i give you my one pro tip whenever i doubted myself in this case and other people nobody else knows it's just in your head as long as you don't tell people that they don't know you you did great man i really enjoyed it thanks for having me yeah yes yeah awesome i'm really happy that you guys enjoyed it and uh whoever is with us after this long journey i hope that you enjoyed listening about hermes and all the details history actually i i feel like we've covered so many great things about hermes that i'm not really sure how we're gonna title this podcast because there are so many great things inside but that just proves that we had a really great time and we had really
great discussions so i wanted to thanks i wanted to thank you guys once again thanks to people on the stream uh readers listeners and all and and people consuming this podcast from all these different platforms thank you for uh being with us make sure to follow alloy and shown on their github and twitter profiles because these um the details are also shared in the description thank you for staying with us once again thank you guys for joining and uh we'll see each other on the next react native show episode soon bye bye ciao
Timestamps
Show
Guests
Eloy Duran
Principal Architect
@
Microsoft
Xuan Huang
Software Architect
@
ByteDance
[Music] hello everybody and welcome to the next react native show episode and today we are here to talk about something very special which is hermes a js engine made specifically for react native and today we are going to talk about it and the recent feature of react native 064 which is hermes support on ios today with me there are two very special guests shin that works at facebook on the hermes team and alloy that works at microsoft so these guys been working together with me on the hermes um making it possible to bring hermes to ios and to maccas which we'll talk about later in a second but before we do it how about you guys introduce yourself to our listeners and the ones that are watching us on youtube just in couple of words so i'm eloy duran based out of amsterdam the netherlands from my house boat that you don't get to see any lovely video feed from working remotely for microsoft um have been doing that now for a year joined to work on react native in office but i have since then moved on to a different team so my knowledge is already getting a bit rusty but i always love to chat and be around go for it sean yeah hey what's up guys um my name is shun i'm also using the handle at hux pro on the internet so i'm a software engineer at facebook working on hermes javascript engine um friendly speaking this is also a very new experience to me i was a funded engineer and writing some javascript stuff so my day-to-day work in a nutshell is implementing and releasing new javascript features to both internal and external react native community so i helped with
managing hermes open source releases and that's how i get to know mike and alloy and to be able to speak here today yeah that's about nice that's that's very exciting i guess sharon we have a very similar background because i also started as a frat and engineer and uh that was also my very first experience with jeremy's um by doing this pr actually i guess aloe was uh kind of having the most experience uh from all of us actually if it wasn't for his help on the uh you know um silang and all these build systems then i would probably pretty last um which is not a surprise because he's been also working on cockapods before right are you up you want me to cover that well i guess you know it's it's it's a pretty interesting contribution i guess i mean it's not even a contribution because you're actually co-author of it so i guess that's pretty um i would say impressive yeah yeah i did indeed start the project here on this very houseboat um but uh and so i guess most more relevant yeah is that i come from the uh the apple ecosystem um and that's so that's why you know i ended up working on ios and mac os related technologies and i've always been interested in crossing you know crossing languages so i didn't do just objective c at the time i was interested very much in at the time in ruby and so i worked on the various ruby objective-c runtime bridge technologies um and thus it was easy for me to try out react native in 2016 in our production application so guys cool that's that's been a while already but you know uh that kind of
proves the point that you know react native is the place where we from different communities can actually meet and collaborate all together from native and from the front end so that's pretty exciting um okay cool so uh now that we know a little bit more about our guests i guess we can move into the main topic of today's podcast which is hermes and i guess it would be a great thing to do at the beginning which is doing a little introduction to what harem is actually is and for those who haven't heard about it what would be its biggest selling point um and i guess sean maybe you want to start as you are actually the representative of the hermes team at facebook yeah so hermes basically is a new javascript engine built by facebook it's designed for the mobile environment specifically to improve the performance of reg native apps but as rig native currently expanding to desktop thanks to microsoft we've seen some of the key benefits are also very transferable to the desktop as well um so for selling points maybe we should pull off the deck let's do it so hermes can help with three primary metrics to improve the user experience so the first one is tdi or time to interactive which is basically how fast your app can start up this is the most noticeable one to the end users the second one is application size or binary size this is comparing to the jsc that can the current default engine of the reg native on android and the third one is the memory footprint or memory consumption so this metrics are critical to model
since the computation and memory resources are much more constrained there because of the form factor and the thermal limits but they are also very helpful to desktop as well so we have some data collected from facebook so we so as we can see the time to interactive is cut to half and the apk size is roughly cut to half as well and we're also able to cut memory by about one third to one fourth let me show you guys uh classic videos so this is open source app and the left one is the recognitive with hermes and the right one is regulated without hermes and you can see the left one uh start much faster than the right one cool so sean thanks for you know showing this deck it really worked quite it really worked great and now uh you know we've seen that you know uh hermes is faster than jsc on android and that's quite impressive um but jsc is not the only engine on android i mean you can actually run v8 or i know that at least historically react native windows i guess used to be running chakra i remember some interesting comments about that so i guess um did you try any benchmarking against the other engines rather than just jsc and if yes what were the results i don't we don't try that internally but i've seen a hacking news that some employee from microsoft office has compared hermes versus va and chakra and actually they already using baiko for va and chakra which is already a little bit more advanced than majority of reg native users and still observe some tti memory and app size wings i think qrs users can check out that hacking news
and i can attest that that person is not just a random person that person andrew really takes his stuff serious so if he says that then he did some serious benchmarking oh that was andrew nice i know him yeah awesome ah that's great so so just to recap the results were i guess showing that hermes is faster right yeah um otherwise we wouldn't be bringing that up right cool so i guess you know it really makes me wonder like how is this possible what is the the magic behind hermes that makes such big improvements possible yeah i think the short answer is that the magic behind all this is what's so called by code pre-compilation which means hermes can compile your javascript source code to optimize by code ahead of that time so your recognitive app will adjust the ship with this buy code and hermes can start execution directly from there um we can go into more details later yeah and actually it just happens that uh later means now actually because that was what i was going to ask you about so it's quite funny but it's all right uh i mean actually uh jokes aside i i'm really curious about it actually you know um like my knowledge and i'm coming from the um front-end developer uh like front-end development was pretty limited about engines actually the first time i've learned about the engine and and compilers was when uh there was a um a uh this github project by james kyle which was like a very tiny compiler and and and that's when i've learned you know about these things so i guess our readers my listeners might be getting quite
confused right now what aot and jib mean and and what's the difference so i guess we can just briefly talk about what does it actually mean in practice that herb uses aot yeah i think first i want to expand a little bit on the meaning of aot versus jit here so i've seen people exclusively regard aot as compiling some program usually written in c or c plus plus to native machine code and mistakenly thought hermes is compiling your javascript to native code as well this may or may not because the that's what wikipedia was saying i actually edit the wikipedia entry of ahead of time compilation weeks ago to make it a little bit more generalized so my take on aot or jit is more valid timing when a compilation and usually the compiler optimization coming with it is performed no matter what exactly the source language or the object languages so for instance in the javascript community we have angular using the word aot for converting its html template and typescript to javascript and the jvm language closure i also use the word aot for pre-compile enclosure code to jvm by code to help with faster startup etc so in my point of view ahead of time aot and it's not really like necessarily opposed to each other we can see java as always com pre-compiling to biker ahead of time and the jvm may or may not jit that bico it can just interpret it there was no jit back to jdk 1.
0 or there could be a jvm like hotspot that can jit compiling the buy code down to machine code to accelerate execution so hermes is basically the same as
0 or there could be a jvm like hotspot that can jit compiling the buy code down to machine code to accelerate execution so hermes is basically the same as
java in this regard so technically there is nothing stopping hermes from adding a jit but we actually experimented with one but we couldn't justify value comparing this overhead so we recently just deleted uh so what does this mean in practice in practice it simply means we're moving as much javascript engine work as possible to the built in of your reg native apps all your javascript source code will be pre-compiled to hermes bico after going through many typical compiler optimizations such as in-lining deco illumination loop environs etc at the view time and when you open your app it will be directly executed from there and from such optimized buy code and that's where some of the performance benefits came from um i think in addition what words to mention is that recognitive across all platform had made this process really simple for react native app developers you just need to flip a switch to enable hermes and that's usually about it um besides android ios and mac os i also heard about recognitive on windows 0.
64 had made herms uploading much easier nice all right maybe just yeah yeah maybe just i think of course maybe for for your for some for some readers that you were referring to are listeners i guess and viewers yeah actually hello hello all of you um i think maybe like so aot literally just means ahead of time right and jit literally just means just in time so in in and of itself it doesn't imply what it is doing it's just about when you do it right so indeed and when like the simplest optimization that can be seen here with hermes when it comes to the bytecode
64 had made herms uploading much easier nice all right maybe just yeah yeah maybe just i think of course maybe for for your for some for some readers that you were referring to are listeners i guess and viewers yeah actually hello hello all of you um i think maybe like so aot literally just means ahead of time right and jit literally just means just in time so in in and of itself it doesn't imply what it is doing it's just about when you do it right so indeed and when like the simplest optimization that can be seen here with hermes when it comes to the bytecode
aspect is ahead of time compilation means the browser or the sorry the javascript engine will not be parsing any javascript code and doing some sort of uh you know compilation thereof that is already done ahead of time right so um so yes good point sean i think a lot of people will easily think that this means something about native like it implies something is really just about when you do the work and then the work that you do can be different things right yeah and i have to say that i really love this explanation because i guess uh before this podcast my aot and jet explanations were usually related to the native code and now the timing itself makes it really easy like even with the css and js libraries you could say that most of them are jet they must have the runtime and there are libraries that don't have runtime because they transpile everything to pure css ahead of time so you know instantly it makes your library fancy because you can say it's aop but you know jokes aside it is actually quite quite a uh simple answer uh to to the difference so i guess uh you know this this is worth highlighting um at this point very good awesome so i guess you know uh continuing this explanation that means you know in practice it means that certain steps with hermes on the react native uh certain steps are happening ahead of time rather than just in time and um if we would break down like all the steps in the pipeline that happened when you run react native app uh what what steps exactly are you know happening ahead of time
and what what is the rest that is still happening just in time yeah luckily we also have a deck for that nice so as you can see from this from the dac we have the built-in on the left which is what happened on our machine as developer and also we have runtime on the right which is what happened on the user device which is usually much less powerful than developers machine so as for all the modern javascript engine basically the entire compilation is happened just in time it just in time compile javascript to buy code then just entire compile the buy code to machine code so the first step will be lexing and parsing so we're trying to parse your source code and find all symbols and functions there and compile to some unoptimized by code i recommend reading or watching the cost of javascript talk or articles from my friends andy osmond from google chrome to understand the parts plus compile can take 30 30 percent of the total time spent on javascript during a page load and hermes can get rid of this 30 so and then this javascript engine would execute a bicode by execute i mean interpolate so all modern javascript engine like va jsc spider monkey chakra has an interpreter before layer jute and then during the interpretation some of the function might be called say 10 times then the base logic is kicked in to compile the unoptimized bytecode to unoptimize the machine code which would be three to five times faster but the generated code is really
huge and that's why va wants to replace their base jit the food cogen to ignition to reduce memory usage and then when a function is called 100 or a thousand times and considered super hot the optimizing jit were kicking and compiled to really compile the unoptimized machine code to some really fast optimized code in reality there might be multiple tiers of such optimizing jit so this code are really optimized because they made assumption in terms of speculative optimization so there is always risk that the assumption is broken by the dynamic natural of javascript hence the engine has to fall back to the unoptimized code this is termed the optimization so pay attention to how many variants of copies of your code need to be stored in memory and how many times your code needs to be compiled compilation is usually super expensive they take a lot of cpu cycles and tons of members to do the work so that's the current typical modern javascript engine pipeline and for hermes hermes tried to move all the heavy work to the building on your powerful developer machine and reduce work on the user device so we will compile your source in the developer machine so there is no need for minification and we will generate an intermediate representation called ssa or static single assignment not social security administration and optimize and optimize that ir to some optimized form of the ir so the key is that we have all the cpu and memory resource to do heavy optimization
in your machine and it's okay to take longer here but for jit engine they usually have to do that optimization relatively quick since its own user device and the code has to be executed there just in time so we will generate a optimized by code bundle in the build type and we will ship that by code to the user device so in the runtime it would be really cheap to just load the buy code it's same as how um a native executable is memory mapped to to the memory and execute it so there is no jute this doesn't mean hermes can have one as we mentioned before it's a deliberate choice that we made for our recognitive workflow yeah thanks for this explanation i really love the uh all the different smaller pieces that you have broken down i guess that really helps to understand the pipeline and now you know i i do wonder why like maybe not what is specific about react native apps that made hermes possible but generally speaking i would assume that uh like after seeing all of this and after hearing all of this it is like quite obvious to me that aot engine is the way to go but on the other hand we still do have like most modern engines such as v8 and jsc uh jit and now the question is why i mean um why is that and what is what is it so different about react native apps that you know would make a good use case for aot then yeah um this is actually a really hard question um so i would try to cover that um i believe a historical context like in the first place was that tdi is really critical to the success of recognitive apps or
actual facebook usage of that so there was a talk by eli white on in the facebook a fa developer conference session talking about the marketplace tab of the facebook app which is entirely in recognitive um and the issue was that it's uncomfortably slow to load it and and and see the first content and being able to interactive on a low end device i forgot the exact number but i remember super slow uh so that was the major point that facebook wanted to solve so i guess people kind of realized the overhead of js compilation is huge during the initialization and people also realize oh recognitive is very different say how the code is distributed to the app is then comparing to delete distributed javascript code to web browser so i think the first difference is the environmental difference or the how or how the code is delivered um so in rec native app usually javascript code is bonded within the app and also we have more control of the runtime environment um so so i guess that's why by code pro compilation makes sense because you can't really ship by code to browser there are different kind of browser using different kind of javascript engine and they use different kind of bi-codes you can just you can't standardize that there is a proposal called binary ast and it's trying to standardize how asc can be delivered and and help with faster startup but it's it's still far from being able to ship by code directly i believe the second major difference would be the workload um so different javascript application have very different patterns
so javascript running on web browsers are super diverse so the engine has to be tuned to be very general purpose uh the javascript engine in the browser tend to have multiple tiers of jit to be able to accommodate that and javascript running on node.
js however are usually very server-like their lifetime tend to be longer and they tend to do very repetitive work uh so and also they need tend to be running in a very beefy machine right so this is an ideal scenario for super highly optimized jit you pay the heavy warm up cost once and then you'll just stay with super fast code in the rest of the lifetime but javascript running rack native apps in contrast are usually more affirmative infirmary um and that's repetitive so during the lifetime of users interacting with your recognitive apps it's more likely that the user will click different buttons and a file very different event handlers so we did some static degree analysis and realized most the function in recognitive during the startup times are executed between zero or one time and even after startup it won't be like a heavy number crunching sort of workload but more like a periodically reacting to user interaction so legit doesn't improve the responsiveness there as well there is also memory concerned as being like usually recognitive apps or mobile apps i've seen people suggesting that for such memory constraint environment even you are using a jit capable engine you might want to turn off its
js however are usually very server-like their lifetime tend to be longer and they tend to do very repetitive work uh so and also they need tend to be running in a very beefy machine right so this is an ideal scenario for super highly optimized jit you pay the heavy warm up cost once and then you'll just stay with super fast code in the rest of the lifetime but javascript running rack native apps in contrast are usually more affirmative infirmary um and that's repetitive so during the lifetime of users interacting with your recognitive apps it's more likely that the user will click different buttons and a file very different event handlers so we did some static degree analysis and realized most the function in recognitive during the startup times are executed between zero or one time and even after startup it won't be like a heavy number crunching sort of workload but more like a periodically reacting to user interaction so legit doesn't improve the responsiveness there as well there is also memory concerned as being like usually recognitive apps or mobile apps i've seen people suggesting that for such memory constraint environment even you are using a jit capable engine you might want to turn off its
jit i i don't have the food contacts but i believe the recognitive apps on javascript c javascript core also doesn't do jit usually yeah and that's actually the thing that we will really get to later because it's not going to be the next question and uh and once again thanks for this uh very deep explanation i'm really interested about this um um this this standard for you know shipping byte code i guess you know on the web that could be pretty exciting so um you know thanks for bringing that up and i guess you know um that brings me to the next question which is you know like listening to all of these it seems to and actually you know hermes has been running on android for quite some time already um and so one would assume that you know it's pretty much complete i guess uh but you know uh like i i'm just curious like what's the roadmap here yeah i think we can start from the roadmap um i guess we are far from being completed i think one thing that people notice is that uh admittedly herm is a little behind of the javascript standard um and also tc39 release features every year so like completing all javascript feature would be always a moving target um so it's definitely on our plan to com support more and modern javascript features um but also we want to implement those features in a way that won't regress there was a reason hacking news about using led cons in jsc was three times slower than using var so we don't want that cons like that so we're also only so we usually only
launch a feature when it's proved to be not request anything or have some improvement there are also features in javascript that are more important to recognitive than else the current promise in rec native is polyfilled with set immediate so promise is scheduled as a priority of timer but not micro tests this is true regardless what javascript engine you're using we're working on improving this since it's required to enable react concurrent mode for recognitive so that's javascript feature coverage the second major focus of hermes is always performance so we're working on some of some significant improvements to our garbage collector so gc is something that you can tune you can tune the space of young generation you can tune when to perform a major gc depending on the occupants and fragmentation ratio so in a more advanced gc you can tune how long do you want to pause or it also not stop the world so we want to keep the pause time reasonably short this would directly benefit the reg native's new architecture because now we have synchronous call into javascript we're also working on reducing even more memory footprint so one of them is called hermes value32 currently all javascript values are represented as tagged value which is 64 bits so it can represent pointer on 64-bits architecture but we're working on a 32-bit version of that with pointer compression another one is small array optimization we kind of observed that most of the arrays in react
app are usually more like a tuple because of the react hooks you you always get a tuple destructure from the set state you stay use reducer that kind of hooks right so we can specialize those kind of small array to use in light storage without actual storage allocation so the third point is tooling we're constantly improving the vertical integration with react native tooling ecosystem such as debugger profiling source map that kind of thing there's currently an unstable transform profile for hermes in the metro bundler where you can drop half of the babel transform to speed up the boundary so working on removing more babel transform and stabilize that profile there are also many other exploration items that need to be proved to be good but in general i think we are tuned for the practice from react native community this gave us some focus and some freedom that other general purpose javascript engine can do last but not least we will always have feature requests from the open source community of course from um from microsoft's perspective um in our partnership with facebook one um big hurdle to making the switch right for react native to use hermes by default was um being able to support native apis that are really important and one the one that that we partnered on is the native internationalization apis so the intel spec because as i understand it but i might be wrong or it's outdated facebook itself doesn't use the native
api yet it is considered a requirement uh for the community before we can make that uh switch which seems like the the responsible you know choice to make we obviously should not uh make it harder for people to do the right thing when it comes to internationalization what i know from that is that microsoft has contributed to hermes the android part of that that's completed for react native windows uh while that while react native windows and macos currently are not a requirement for to to decide what gets enabled by default you know in upstream react native uh there is the aspiration to be in sync and so react native windows currently does have an implementation of the intel apis but it relies on something called icu which you know it's just like let's just say it's like a a globally uh used uh api to power internationalization so it comes from the unicode consortium if i recall correctly uh but not all platforms provided and you know it has a lot of metadata so it's that's something that you want to ship with the with the application um and so i don't think all windows platforms provide icu or at least not in a way that you that any application can use it and so the current effort was to port that work to use the sanctioned what is it called windows globalization apis and actually the same thing was on my plate to do for mac os before i transitioned to teams i can't say what the state of it is right now but the issue is pretty much the same mac os
and ios both rely on icu to do that work but one of them only one of them provides a little bit of the api to applications otherwise it is on it's considered private and so it's also unfortunate that we can't do a straight port of the existing android work which uses icu directly to these other platforms uh they have to be you know transpiled i guess in a sense to not use icu but use the sanctioned api switch on windows is the globalization apis and on macos and ios is the just the core foundation apis that allow for some internationalization so it is interesting you know how facebook doesn't even actually use those apis but it is considered essential to the community right as always we always have to balance uh what is the right thing to do for the community like what is our vision of how what type of applications react native delivers um and this is just a responsible thing to do yeah that actually makes me wonder what is it that facebook is doing internally if they are not using the intel apis uh probably something custom right i hear that i have a few more engineers than the average application developer so you know yeah yeah well that's that's that's right uh but it's it's great to hear that you know there is an effort to make that uh work for the community i guess that's really great that you know you're still keeping that perspective in mind is there any place where one can track the progress of this like a github issue umbrella issue or a project or something like that we can link later in the podcast that's a great question i i let me find some i think i'm all the work that we in our partnership
agree on taking on is should be public so i'll find the link and we can link it okay cool yeah we can uh we can include it later in the uh description notes so um if you are listening to this part uh you can check the description that's where it should be so definitely upload for microsoft uh the intel work from microsoft so hermes has been really great for us at facebook um so as eloi mentioned there have been a few blocker that kept the community from being able to adopt it notably proxy and intel each had over like 100 thumb ups on the feature requesting issue uh so for the proxy we recently make it default and release with the reg native 0.
64 and that actually a feature facebook doesn't use in internally as well so it's built entirely entirely for the open source community and the intel works thanks for sex for microsoft the android intel support is very close to completion um we the plan is to release intel with recognitive 0.
65 for android so stay tuned for that uh as for what facebook use internally for internet internal rationalization we use fbt which is also recently open source so so the intel api is also for the community i kind of would like to do another podcast on fbt because i just googled it in any time when you said it and uh it's it's quite interesting um you know approach like like it's it's always an interesting um you know like concept when i see you know facebook having their own uh implementations of things that we would say are obvious and are
64 and that actually a feature facebook doesn't use in internally as well so it's built entirely entirely for the open source community and the intel works thanks for sex for microsoft the android intel support is very close to completion um we the plan is to release intel with recognitive 0.
65 for android so stay tuned for that uh as for what facebook use internally for internet internal rationalization we use fbt which is also recently open source so so the intel api is also for the community i kind of would like to do another podcast on fbt because i just googled it in any time when you said it and uh it's it's quite interesting um you know approach like like it's it's always an interesting um you know like concept when i see you know facebook having their own uh implementations of things that we would say are obvious and are
you know sort of publicly assumed to be the go-to choices and still the facebook scale sometimes leverages you know basic problems and shortcomings that at your scale just don't work and so that's why it's always you know great to have uh sort of um deep dive into you know reasonings behind these so uh definitely going to write down down for the for the next podcast but i guess we can wrap up the first part and quickly move to the second part which is uh not about the hermes history and and the hermes state and android i guess we have covered that pretty um pretty deeply now i wanted to talk about you know something that is very exciting and very new as of react native 0.
64 or something that has been released recently which is hermes uh support for ios and something that releases a part of react native 0.
64 but as a part of react native mac os which is hermes support for react native macos and i guess because i was involved in working on that and i know that my work on ios um wasn't the beginning it was actually mac os where it all started i guess allo it would be great um if we started with a bit more context on like the democrats work like like i have to say that i'm really impressed uh that microsoft has been investing in react native so much and that is you know supporting desktop mac os platform as well even though it's not you know their sort of environment it's windows of course but it's really great and so i'm just like curious about like uh the maka's support for hermes what's going on there and why it's hermes and not chakra for example and and how that relates to react native
64 or something that has been released recently which is hermes uh support for ios and something that releases a part of react native 0.
64 but as a part of react native mac os which is hermes support for react native macos and i guess because i was involved in working on that and i know that my work on ios um wasn't the beginning it was actually mac os where it all started i guess allo it would be great um if we started with a bit more context on like the democrats work like like i have to say that i'm really impressed uh that microsoft has been investing in react native so much and that is you know supporting desktop mac os platform as well even though it's not you know their sort of environment it's windows of course but it's really great and so i'm just like curious about like uh the maka's support for hermes what's going on there and why it's hermes and not chakra for example and and how that relates to react native
windows are you planning to bring hermes there as well that is a lot of questions mike yes i know i'm sorry like i've been waiting to this part to ask you all of these questions i just couldn't control myself gonna stop myself from like asking five of them at a time well we can start with the uh background on like hermes and macos how is how it all started and why hermes and not chakra let's say yeah well i think you know i think actually it probably answers a few of your questions in one go um so yeah so let's see so let's back up so microsoft uses react native in office right um and it uses it to i mean look office itself is not written in react native that would be that would be silly from the perspective not that javascript is silly but it's like office is a code base that has existed long before the humans roamed the earth right it's like this it's such a large code base it exists react native is mostly being used right now to deliver what they call experiences so you know small pieces of widgets like integrations into the larger applications and we want to allow partners to build these widgets without needing to think about the large matrix of like where's office deployed to what different ways do you need to compile it um or even have access to all of those you know apis that that will be needed for that so having like a being able to use javascript for that is a very powerful way to do so which obviously has been done many times before also in office in the form of you know a
web view just just put a web view on the screen and allow somebody to write some javascript and html but i think i think for the listeners to your podcast it's already pretty clear why you would choose react native over something that is basically just a webview so we don't need to go into that that's the same you know that's the same case here um so so that is definitely like already a requirement that's why microsoft not the only reason but that's why office is you know invested in making sure in using react native but react native obviously is a um an open source project in a sense at least so far that the things that we need might not align all the time or are not needed all the time by for instance facebook like you know like we just discussed with the intel apis etc and so if we want to have a stable environment we need to contribute to that uh right and so um that is why we invest in it and also not just in the only in the things that we need but as a platform right and we want to unlock people to to write um applications more easily not just for ios and android but in the same way for mac os and windows right um so that's that's that's all sorts of good business reasons to uh allow to help flourish a otherwise uh open source uh project that is in many cases run by a lot of people in their spare time right um and so so clearly microsoft has already looked into prior to hermes into other solutions like we also saw from the links to hacker news article
but you know chakra itself is is on its way out in microsoft just entirely so there would be no point in in then resurrecting that for mac os um [Music] so v8 would be you know an an interesting alternative and i i know that there has been a lot of testing i don't know in how far it has actually been rolled out but you know it then it comes down to trade-offs and when we are talking about trade-offs you know settling on a single engine that is shared is hermes does not necessarily always address all the same uh optimizations on each platform but there's something to be said for having a a single uh engine that is um malleable and and targeted to this environment right so we can have rather than rather than spending hours of microsoft engineering time and i can tell you there have been many hours in trying to get you know debugging to work with edge chrome vs code to various to javascript core to v8 you know that is time that we could better spend on making flipper even better right um and and and we have that time because first of all hermes is entirely accessible to us if we need to hermes to act a little bit different for this case then we can do that right um and that is actually a thing with um uh remind me the names all the names the native more synchronous access to native modules um is it fabric module two modules yeah no i think yeah maybe i mean it's all intertwined right so i think one of the issues no
definitely uh turbo modules and i thought that was some intersection with fabric as well uh but um you know there is some cases if i recall correctly where you want we want the users to be and the users are the the react native developers here right to be able to debug their javascript but that javascript might then go into an asynchronous like a blocking native call and that is not something that the typical uh chrome debugger protocol uh expects that's because that's not a thing that those the the engine does in the same way and so uh with hermes um it is it is feasible to have this implementation of the protocol that tree that allows for the for that type of stuff right so we have very specific needs in react native and having then access to a javascript engine that allows us to target these specific needs means that it is it's going to make the overall experience better and we can standardize it in a single place rather than trying to patch it onto all these different places right which is actually kind of like very much how i at least like to react native over ui kits and apkid development because if you if you if you have an issue you can actually go in and fix it uh rather than patching around it so so i guess that so that answers why we you know why for microsoft we would go with hermes rather than another engine so there's many there's multiple reasons there right um yeah because um in some cases like like you mentioned like the ap something like the ap apk reduction is something that applies very much to
android and shipping like a jsc that is good for react native that is not something that necessarily applies to ios or macos right like we have good jses but as with many thing in engineering it all boils down to the the sum of all things and that you need to make those trade-off decisions and so up seeing choosing a single one allows us to be to have a much better developer story for much better uh place where we can optimize things in the long run so that's kind of what it what it boils down to a lot of them which is great and now i actually have so many follow-up questions to you but i'll just stick with the latest one um you mentioned that you know like like the bundle like the apk size optimization while being an improvement on android is not necessarily a uh improvement on ios and mac os which is quite obvious uh because jsc kind of comes with the platform so i guess uh the question would be like what would be the selling point on ios like for android everybody knew that you know there were some issues but like i always felt like ios was the um faster platform more stable platform and i guess generally apple ecosystem so i guess uh what would be the selling point for ios rather than just having the unified engine that you obviously mentioned before well i want to be clear first that the apk size is an issue now uh shun can probably better speak to the road map but there's inherently nothing stopping the hermes developers from making so many optimizations to the byte code that it reduces the overall code size there you go
um so it's not necessarily the case right now that is the case and last time i measured at least right um so given that right now that that's that's not necessarily a choice to get well look um i think a lot of people that have also experience with server development right that's the trade-off there is like will we spend a lot of engineering hours on making this code very optimal or can we just buy a few more servers right so sometimes you need to make decisions that are that seem a little uh unintuitive and in the k in this case uh yeah the initial download might be a little larger but if your tti goes down uh that's you know that that might look the the download time that a user pays and look i i am no expert in this right that's probably people that have looked into this data a lot but the downloads time it takes and increases is a one-time cost whereas the application launching hopefully is not a one-time cost right uh hopefully they love your application and they will launch in times and so uh if you're into user experience and whatnot you know that's the perceived performance over actual performance and sometimes something that feels better is just better for the overall uh expectation which i don't think in this case actually applies in tti is actually faster and that is the goal right we do skip things like parsing etc things that just aren't aren't necessary in a controlled environment where you know the javascript that you ship etc so those are the types of things that i think would matter more i think in terms of right now
but don't pin me to this this might be something that sean knows better uh you know that's that's things like um intrinsically because of how the byte code is loaded from a single file you they're they're they're they're uh the memory is it's not loaded entirely into memory it is memory mapped and so it the the uh the os can better uh move around memory it can like take parts of them it can take parts of the of the code out of memory when it's needed uh without the application needing to allow for that which uh apparently is something that is harder with uh traditional um uh engines um so you know that's there's there's various different reasons why one would choose for it and there's also it also depends on the audience right in our case yeah people making and maintaining things it's definitely standardizing on a single thing makes a lot of sense for users your initial tti might be what you care for look if you don't care for that if you really care about optimizing for apk size right now in ios then we should just be clear about that right you should use jse hermes can potentially still have perf advantage on tdi from the bicycle pre-compilation those advantages but also for memory uh so mind map as eloy mentioned has basically two advantages for sino the first one is like say you have multiple javascript module which will be compiled to different biker module then that is something that you can lazy loaded each module into the memory whenever it's actually used um when operating system paging those uh buy code module and the second one is that we can easily return back memory
uh back to the os and that's really cheap there is also um vertical integration that hermes can possibly do like if you if you donate function name we can strip function them and also we have some static building optimization or string duplication that is very kind of specialized to recognitive usage um the second advantage in general would be the having a consistent vm across all recognitive uh platforms that allow you to mention yeah like providing a consistent debugging experiences and having better uh tooling integrated with recognitive ecosystem yeah and and i guess that was my first uh first you know the first thing that came to my mind that you know having a unified engine certainly makes it easier for all of us to focus on you know delivering certain features and tooling uh instead of you know having separate developer tools for like each engine which are obviously different because for example the debugging experience is different with hermes and different with you know jsc for example which is one thing that i wanted to add on top of uh like um what you said before alloy um regarding the memory mapping there is actually a um and i'm gonna do a uh sort of humble track right now uh since we are working on a project called a react native webpack handler previously known as hull uh the name is to be verified because we just realized we are actually using two trademarks in the name which is you know kind of a legal challenge to handle right but um the point is that you know we are we do have this uh sort of uh we are working on the future based on module federation which lets you kind of
split your bundle into smaller um js files that you can dynamically load and that is kind of a evolution of the ram bundles that used to be supported for the jsc then i guess right now they are not working quite well and obviously with hermes and memory mapping there is no a clear uh sort of need for it and then for for kind of fixing it so i guess that's the direction we are moving uh cool so um i mean i just have like two more questions about you know hermes and ios and hermes in general and i guess you know something that has been you know asked ever since we started talking about hermes and ios from the very beginning was what apple is going to tell uh during the review process and i know this is the most favorite question that everybody is asking like uh like like what will apple say and obviously you know we know that uh hermes is iot so technically speaking everything should be fine um so i guess you know like i kind of just realized that i answered my questions already but um i wanted to check with you guys what you think about it like uh do you feel like the aot uh was the primary reason why apple like didn't accept traditional engines and and that is what makes it uh possible uh potentially in the future to build apps with hermes and ios and mac os i think this is uh interesting territory and i'm glad that you already have how you started it i like how you already answered the question i i look let me let me let me tell you a different story
once upon a time i worked [Music] on a startup in a startup [Music] that was called rubymotion and it was an extension of an open source project that i collaborated on um and it compiled ruby to native code um for ios and mac os that was you know mac ruby was for macos and so you know ruby is also dynamic and um thus the obvious choice would be a jit engine um but apple you know they they have had uh i don't know what the what the the wording on it is now but the they in the past at least there has been very clear wording about jit not being allowed and jit again is just words right it just means just in time so to be clear in this context it means compiling code to native code in memory and marking that memory as executable is not allowed and the reason to do so is uh is good because it adds a security risk um right and so so i get that um but i can say that you know with ruby motion we so we did not do jit we did entire aot compilation and that was fine so right so the the the point is mostly that we cannot we and this is purely again about the aspect of uh when people often think about the whole something jit something aot and apple right this is that's what this is about it is about compiling code to native code and marking it as executable in like in memory that is not allowed and that is not something that hermes does yeah now then there's there's lots and lots of other texts about javascript etc you know that's like a whole diff that's
where that's why it gets so confusing to people but when we talk about when people talk about the jit aspect it's very clear what that's about that's about this thing and the harems does not do that assuming that everything goes mostly and we do have you know hermes and ios uh available as a as a as a as an option that you can turn on in your pod file and we do have it on android in a similar fashion uh and and it starts being accessible and available in other platforms i guess eventually uh there there is a plan to make hermes the default it's probably still early stage to speculate about ios and other platforms but it makes me really happy to see you know all these improvements happening to ios android and react native in general like the architect re-architecture and all these pieces changing and improving in the experience performance that's uh that's really great um so i guess you know the last thing i wanted to talk about but i guess uh we are probably um yeah like we recorded so much material that you know it is going to be better if i do another humble brag again i'm um i'm i'm working on an article uh where i go through the details on how hermes was implemented on react native um for ios including you know various different pieces of the architecture that made it possible so if you are interested to learn more about how to turn it on uh how it is possible to make hermes compile on ios and mac os because i also link to the microsoft work and alloys work um go to the link to the article that is in the description as well that's where you will be able to learn more about the technicalities
and how hermes integrates with react native itself and i guess that brings us to the end of this podcast which has been really exciting and uh first of all i wanted to really thank you guys for joining uh and and i wanted to thank you for all the work that you did on hermes on macos ios 100 because that's been a tough and really challenging work and again i'm really happy that we are doing this today after rescheduling for quite some time so once again thank you very much and i i hope that you enjoyed it well it's it's truly really nice to meet you guys and chat about hermes and rick native especially in this quarantine theory um i'm i'm i'm glad i went through my first public speaking english it was a tough a little tough yeah that was your first time definitely my first public speaking english and first podcast i wouldn't tell like it felt like it felt like like you did it like a pro so and i'm not kidding like should i give you my one pro tip whenever i doubted myself in this case and other people nobody else knows it's just in your head as long as you don't tell people that they don't know you you did great man i really enjoyed it thanks for having me yeah yes yeah awesome i'm really happy that you guys enjoyed it and uh whoever is with us after this long journey i hope that you enjoyed listening about hermes and all the details history actually i i feel like we've covered so many great things about hermes that i'm not really sure how we're gonna title this podcast because there are so many great things inside but that just proves that we had a really great time and we had really
great discussions so i wanted to thanks i wanted to thank you guys once again thanks to people on the stream uh readers listeners and all and and people consuming this podcast from all these different platforms thank you for uh being with us make sure to follow alloy and shown on their github and twitter profiles because these um the details are also shared in the description thank you for staying with us once again thank you guys for joining and uh we'll see each other on the next react native show episode soon bye bye ciao
Show Transcript
The episode #5 is all about Hermes: Mike and his guests discuss its technical features, biggest selling points, and possible future developments. They start with the basics though, so at the beginning, you will find out what Hermes is and what it actually does.
Bringing the Hermes engine to iOS
- Hermes improvements to React Native apps in terms of three metrics: Time To Interactive (TTI), Application Size (APK), Memory consumption
- The “magic” behind Hermes - “Bytecode Precompilation” a.k.a. AOT
- The difference between AOT and JIT
- JIT JS engine pipeline vs Hermes pipeline
- The Hermes roadmap and plans for further improvements
Hermes support for MacOS
In the last part the focus shifts towards bringing Hermes to React Native MacOS. Since Microsoft recently added support for Hermes on MacOS, Elloy describes the process behind it, mentions the solutions considered prior to Hermes, and takes a quick look into the future of Hermes support for MacOS.
- What was the motivation behind adding support for Hermes on MacOS? Any plans for RN Windows?
- Were there any attempts to bring Chakra to run on macOS, to say, provide more unified experience across desktop platforms?
- On Apple devices, unlike Android ones, there were always less of performance and memory related issues when it comes to running React Native applications. What would be the selling point of Hermes in such a case?
This and much more you can find in the Episode #5. Pick your favorite platform and check it out!
Want to achieve better performance with Hermes?
We guide teams in optimizing React Native with the Hermes engine.
Let’s chat
//
Insights
Learn more about
Hermes
Here's everything we published recently on this topic.
//
Hermes
We can help you move
it forward!
At Callstack, we work with companies big and small, pushing React Native everyday.
React Native Performance Optimization
Improve React Native apps speed and efficiency through targeted performance enhancements.
React Native Development
Hire expert React Native engineers to build, scale, or improve your app, from day one to production.
