RNEU 2020 Conference Q&A Panel
Subtitles
Show
welcome everybody to the next react native uh show podcast today we have a special edition which is also a react native eu panel and today with me we have very special guests that will be answering some of the most interesting questions that you have been asking during the react native conference so maybe let's do a quick introduction of every guest starting from my left side so i guess the first person to go with eli eli if you could introduce yourself what are you doing at your day job what are you doing with react native on a daily basis and essentially everything that you'd like our listeners to know about you oh that's an interesting question mike um so i'm eloy i currently work at microsoft um and i work on their react native needs in office um which day-to-day means that i'm working on getting mac os react native uh up to speed with the other um versions that exist um and also helping out the community with some things like uh getting the releases out etc otherwise let's see i've yeah i worked on cocoapods dependency manager and the ios mac os space so i have a lot of int i've always had a lot of interest in the where native meets scripting other languages um and that's how i found my way to react native when i worked at artsy interesting yeah i i seen a couple of your recent pr's around native code i'm not gonna spoil that word because there is some exciting stuff coming up so we'll probably learn about that in the nearest future thank you for that so the next person is paroshuram ram now it's your time hey everyone my name is ram i'm an engineering manager at facebook
and i'm currently working in oculus oculus if you haven't heard is the virtual reality reality headset that uh facebook produces and at oculus i'm mostly working on uh react and reactive based 3d systems for uh 2d systems for a 3d environment before this i used to be on the react native team where i was working on the re-architecture of the application specifically on turbo modules and have done a lot of work on performance uh i've actually been associated with react native even before i was at facebook before facebook i was at microsoft and if you folks remember code push i was a pm on codepush trying to like help people push their code faster and i also helped build the vs code plugin for react native building mobile applications for ios and android using javascript is something that's always near and dear to my heart in fact i'm also a apache core committee member of the apache cordova project or more commonly known as phonegap project and during my time at microsoft i've done xamarin so as you can see i like played around with all the technologies which is not java and objective c that you can use to build mobile applications that's me that's really exciting and i think uh when i think about the first time we met i think that was in a conference uh in us when you were when we were talking about code push actually that was back when you were in microsoft that's been quite exciting times when you know coldproof was just starting so uh that's been quite a while ago now i think okay uh thank you thank you so uh the next speaker is monica uh monica if you could tell us a few
words about yourself and what you are doing uh with react native on a daily basis sure uh hi all so my name is monika um i'm a software engineer at major league soccer and i'm currently working in a few exciting projects within the league but mostly focusing a lot in mobile development with our mls app um our app is what we call a hybrid app but but about 70 percent of it is built in react native and then the rest uh swift and kotlin and um that's what i how i use my time at work nice um that's that's that's pretty exciting and how do you like kotlin compared to java what i like about it is the automatic conversion when you copy and paste the stuff to the jetbrains editor that's a real killer feature yeah okay thank you about this uh so uh the next and the last guest on our podcast today is kudo kudo if you could tell us a few words about yourself that would be awesome okay hello i'm kudo i'm a software engineer of clamosa uh day job is about development of browser so i'm really a part-time job for part-time for real native because my day job totally not related to real native at all for the part time i have some side projects such as real native v8 and i also previous a javascript core antenna and this time i have a really native skier so and from the deja i got most familiar with chromium core best because we are doing browser based on chromium so i got a lot of them are familiar with chromium copies that's why i do ba or skia splatter as well nice nice that's that's really exciting and um i think i already said that during
the conference but uh when we met for the first time i i remember your messages in those you know c plus plus related channels on the discord community uh that's been always blowing my mind for a while i even thought that you were working at facebook because the amount of comments about turbo modules made me think that you are maybe actually working on that and then it turned out you are actually an external contributor so uh respect for for for that um all right so uh thank you for introducing as you can see we have a really really great i guess today to talk about react native so maybe let's start with a react native eu question uh how did you like the conference what was the most uh exciting thing about the conference that you liked so far and um we can start from eli first hey i well i really liked that it was online of course as you know i am always a remote and also i i think wasn't it react the first react native eu that i broke my uh um i was on i was i stopped doing any conferences and then i figured like okay well i'll do this yeah i was proud of myself that i can't convince you yeah yeah so i i really like uh not having to travel and do it remotely so i think that was definitely the upside part for me um the talks that stood out to me and that wasn't necessarily one that actually that stood out the most to me i just really enjoy hearing other people talk about react native um um because as you know i work alone here in the netherlands and it is it is fun to have these people talk i enjoy being at the conference talking with people about what they're doing day to day
and that's what i enjoy most about the conferences and having this conference around the this technology that is so exciting to me um so i think that's the most the best part to me awesome who wants to go next i'll go um well i have to go with the lies as well opinion and um it was amazing that it was an online conference um you know having the idea of having people from all over the world just like being able to participate was very interesting i really enjoyed the quality and technicality of all the talks um if i were to pick my favorite i think i'll go perhaps with modernizing react native's javascript by um the us eli as well white i can't remember how to pronounce his name but i'm sorry for that um yeah so i love um i just really love you know like one of the reasons why i go to these conferences is just uh to look for some deep dives into complex relevant topics um and i think this is uh something that this talk in particular did um you know um his talk was really descriptive uh easy to digest and definitely just enlighten any many things so um i'll just pick that awesome ram or kudo i can probably go next i think one of my favorite things about conferences is i usually don't attend conferences for the talks themselves but for meeting people i think like most conferences have talks recorded and posted online but it's that whole connection that you have with your fellow developers who working on like similar problems trying to listen to them and figure out how what kind of similar problems you have that that has been something that's always been like uh of interest and honestly when like
mike pitched this whole idea of hey we're going to do a reactive you i was a little skeptical to start off with i was not sure if it's going to have the same like essence of the conference uh i should say that i was pleasantly surprised in fact uh it was super it was like very interesting to see how on the slack channel people were talking to each other and there was like this whole set of like side conversations that were happening people helping out each other so i can actually say that i did feel that sense of community and honestly react native is a very inclusive and welcoming community and this the slack channel was an embodiment of that uh also i don't know if many people who watch react native eu know this but mike i'm probably going to let out a secret the talks were all recorded they were not actually happening online so that did relieve a good pressure from the speakers and i think what happened was that effectively freda freed the speakers up and helped them answer the questions as the questions were popping up during the uh during the talk so like the slack was super active and the whole community building was was my favorite part about reacting to vu online yeah and i i have to totally agree with you at that point you know usually we are super stressed when it comes to organizing this conference here in roswell but because you know some some of the stuff was already prepared up front we were able to also have slightly less uh i would say intense time during that week so definitely something that uh we will be you know missing from the next year if if it's gonna be happening on site
um cool kudo what about you uh for me i like the topic because there is a diversity from architecture from javascript day-to-day development graphql and about the animation for me i like the animation topic them very well especially inspire me for the animation differences between web and mobile that is really inspirational topic and i also think you think to the conference about the it's a virtual virtual camp because i used to stay with my family and with this chance i could have a talking this year yeah i think we even talked last year when i tried to convince you to submit a cfp and you said traveling will be impossible and this year you know it was finally possible so really really really happy that we made it uh all right uh all right so we are warmed up we are ready to dive deep into the first group uh so just for the record i have grouped uh the questions into three groups uh and these groups are at the new architecture of react native multiple platforms and general development so just general questions uh that people were interested to have answers for uh so let's move on to the new architecture of react native so just to quickly recap last year react native team announced a lot of changes uh to the core of react native that you know addresses a lot of challenges we're facing when it comes down to building applications and that includes turbo modules which is a new implementation of native modules for better performance on synchronous access code gen to ease creation of native modules by synchronizing the type definitions and missile declarations between native and javascript
gsi which is javascript interface and it is a unified lightweight sort of general purpose api for any javascript virtual machine and it enables every uh other piece of the re-architecture and is what for example makes hermes integration very easy and you know easy is obviously really relative here um and then fabric which is just the ui re-architecture to take full advantage of you know these features and concurrent react architecture so while this work is still in progress we can see a lot of these already in the open source and i think it would be great uh to to sort of go over the latest updates than the ria and i think that questions uh from our audience might be a great starting point uh to our discussion so uh so the first question that i have here is you know what is the status of the re-architecture and what are the changes that are already shipped and when do we expect to have an update on the rest of them and i think the best person here would be ram that is you know even wearing facebook t-shirts so uh that tells uh tells it all sure so i think this has been a question that people have been asking and uh i can clearly see how people can't wait to get their hands on uh like the new architecture but i want to be like amply careful here about talking about like there is no release for the new architecture in the sense that there will not be one single date where it's like things stop and like suddenly react natives which switches over to the new architecture uh our initial plan was definitely trying to get it out in 2020 but unfortunately coveted a lot of people their productivity kind of went down and
as a result we may not be able to hit 2020.
uh we are looking at 2021 as something that uh where this can get out but i mean i don't have a specific date in mind but let me also lay down what what does releasing it really mean so uh let me talk about a little bit on what what's happening in terms of how how fast you're going internally and then talk about what's available externally so internally i think on the main facebook app we are actually testing fabric we are testing our turbo modules and honestly jsi is pretty much the way to go for both fabric and turbo module all of our native modules are code giant in fact we also retro cogent the existing modules there's like turbo modules tech and stuff for existing modules also so the testing is heavily underway we are seeing some really exciting results both in terms of performance and in terms of stability and i think one of our biggest motivations here is to ensure that the transit transition is smooth and stable more importantly like people's apps don't start crashing and that's why we are being exceedingly careful we've also started to roll out fabric and turbo modules to internal apps for example the oculus companion app that i work on we are starting to roll out turbo modules in it fabric is a little bit harder because we wanted to do it screen by screen and for that you need native navigation which we are trying to move to uh and this is a similar story with all standalone applications so i think the best way to think about it is internally in facebook apps we are slowly starting to roll out fabric and tower modules uh
uh we are looking at 2021 as something that uh where this can get out but i mean i don't have a specific date in mind but let me also lay down what what does releasing it really mean so uh let me talk about a little bit on what what's happening in terms of how how fast you're going internally and then talk about what's available externally so internally i think on the main facebook app we are actually testing fabric we are testing our turbo modules and honestly jsi is pretty much the way to go for both fabric and turbo module all of our native modules are code giant in fact we also retro cogent the existing modules there's like turbo modules tech and stuff for existing modules also so the testing is heavily underway we are seeing some really exciting results both in terms of performance and in terms of stability and i think one of our biggest motivations here is to ensure that the transit transition is smooth and stable more importantly like people's apps don't start crashing and that's why we are being exceedingly careful we've also started to roll out fabric and turbo modules to internal apps for example the oculus companion app that i work on we are starting to roll out turbo modules in it fabric is a little bit harder because we wanted to do it screen by screen and for that you need native navigation which we are trying to move to uh and this is a similar story with all standalone applications so i think the best way to think about it is internally in facebook apps we are slowly starting to roll out fabric and tower modules uh
like ironing out the issues and any uh edge cases that we encounter as far as open source is concerned uh you'd actually be surprised but both fabric and turbo modules are out there i think the biggest challenge is it's not buildable and that's only because facebook internally uses buck so all of our build scripts are reliant on bug now this is where i think we can use some help from the community and i think someone did this for ios where they picked up the ios turbo modules and fabric systems wired it up into the xcode build and they were able to build it we haven't done that on gradle yet so if someone is brave enough and wants to try this out i would like to recommend this as a really good project where you play around with gradle and enable like a turbo modules and fabric on rn tester for example uh it's not as hard as it looks it's basically a bunch of magic around graded scripts and android dot mk the c plus plus wrapper so that's the current state of the world a lot of codes out there i think eli also spoke about like code generation and uh i think it is in a state where you can try it out test it out but i'm not sure if i would recommend it for production yet mostly because it's not officially supported yeah yeah yeah yeah uh thanks for answering that and actually you would be surprised that i i mean i'm not i'm not surprised because i've been there already how how quickly sometimes it might be how easy it sometimes might be to to kind of release some of these internal pieces into into react native for ios for example on the on the hermes side uh compiling it for ios is theoretically just you know
doing some changes to the cmake which on h1 is very hard but i was kind of surprised that you know essentially the code is just c plus plus so as long as you compile it it theoretically can run so not a lot of magic there inside uh as someone would think um awesome so um so that brings me to the next question where where i could track the progress of that uh in the future for example uh so i think monica also wanted to answer this but let me quickly give a feel of like the discussions repository and the history which i probably haven't spoken about so i think almost one year ago when i was in react native team i realized that there was a lot of discussions that were happening one-off and one of our our goals in the react native team was to be inclusive and ensure that every discussion is transparent and people understand the rationale band what's happening that's the reason why we created this repository called discussions and proposals where people like anyone in the world can submit a proposal people can critique it look at look at what can be implemented and then go ahead and implement it so we have this proposal called discussions and proposals and uh there's a there are issues related specifically to turbo modules and to a fabric uh that's where most of our updates are happening unfortunately those issues could also be noisy because usually for every single update there's like 10 comments asking hey when is it ready uh so you might want to you want to you might want to add on your noise filtering in there but i think those are probably the best places that you can look at it's also a place where i'd recommend if
you're experimenting with turbo modules for example just go add your status there and tell people hey here's what i've tried out and people might come asking you i think also that um if you allow me to jump in in addition to what ram just said uh intuitively the first place that i a particular go and i will recommend people who are just getting into is um of course the react native repo where we also have like a bunch of like issues being discussed and the react native community repo in particular with the react native community repo i found it very useful especially their releases uh section um i believe and correct me ram if i'm wrong it's like one of the most reliable places to go um you know in regards of staying up to date with uh status reports and and you know uh all what's going on um with react native overall um and then just the usual just chain logs and then release notes from uh from your team at facebook i think it's also um yeah just like tracking all those will be pretty effective in just keeping um you know any developer up to date cool uh so so what is the feature you're most excited about um i don't know what you're asking me okay so these well we've been talking about how big this new re-architecture of react nato would be or is like kind of the process of being and of course there are a lot of things that will be definitely um game changers um and the way we develop apps but if i have to pick one i'm definitely gonna go with turbo modules um you know this new feature that pretty much tackles um
you know the most in terms of performance and safety and um i really like the idea of having tape safety between native uh code and javascript and uh particularly for uh particularly for us at mls this is really important because we we do have a fair amount of native modules and integrations um with uh third-party providers so um you know the overhead reduction that turbo modules introduces when calling methods from the javascript side is something that is really really going to help us with performance um you know among with the faster startup when initializing our application so definitely turbo module for me nice i like that i like that as well anybody else want to chime in here uh for me it's probably going to be jsi uh because gsi is like the fundamental layer that's the on which all of these things are built and you'd actually be surprised but all the other hybrid mobile app development platforms have a story similar to uh jsi for example if you look at native script native script actually has a way to generate all of these javascript files based on templates like you take a java class it automatically generates all the methods and exposes them to javascript and the mechanism they use is something very very similar similar to jsi in fact jsi is also fundamentally the way a browser exposes its native apis to your javascript player so looking at it in retrospect maybe we didn't really need a bridge back then and we could have just used gsa but uh i would like vote for jsi mostly because it's like the founding block
of the foundation of the entire system and js is also already ready so you can technically start using gesso right away not just for fabric whatever modules but even let's say you're building your own uh javascript layer on top of a javascript engine jso would come in very handy yeah i i'm uh probably most excited about uh fabric um ever since initially when we explored uh react native at artsy i think i spent a month trying to just get react native to work with ui kit as i was used to it um and things like uh i don't know a ui collection view or all those sorts which with the artsy app you know there's so many images shown and you want to have fast scrolling and fast interactions that that was kind of just uh it felt like a necessity in the end i think the app works works really well with jag native as it is but you know conceptually i think having the ability to do such a synchronous ui work will probably pay off in in in areas where it is noticeable that react native is somewhat lacking for me i also like the fabric of your more excited about fabric as well from my talk i said that uh for third party development developer to have a out of three platform is really really a disaster because the upstream changes really change every day and so for especially for the individuals it's really hard to have out of three platform and now with the fabric most of core is also cross-platform so i think it will benefit for the new platform and method is possible yeah i i totally agree with that and i think that brings us to the next section which is kind of related to multi-platform uh
react native so react native running on other platforms and at the end of the day uh everybody who's been ever maintaining a separate regulative fork has been running through that kind of problem that you have mentioned so um so so from the very beginning react native was obviously about cross platform and while it shipped only with ios and android or i think the android was actually added a few months later um everybody knew that you know other platforms are eventually just a matter of time when somebody will start working on them and this year we've seen a lot of great contributions from our partners in the community including microsoft on additional platforms such as you know windows and surprisingly mac os and and we have received a lot of you know questions from our audience on that aspect and in the general direction of the framework in that area so i think we can start off with a question with the first question which is uh which is which is um uh kind of about sharing the code between mobile and web so with the new platforms being released and becoming production ready uh what opportunities do you envision when it comes to sharing code between mobile and web traditional react and react native targets and desktop environments do these have a lot or something in common uh and i think uh like maybe you want to start as you're representing actually uh the the microsoft here as well uh and you are working on uh windows and mac os parts of real native yeah well so i think um you know clearly any code that is not
necessarily ui related or particularly dependent on the os will be easily shared as plain javascript um so that is definitely already a win i think i can imagine like if i take the rt app as an example porting it to desktop means that all the the data layer would would just work um so the piece and then when it comes to the ui large pieces of the ui would work i think people are familiar with catalyst it would be somewhat similar to that you are able to leverage most of the ui but obviously there are some paradigms that you only have on desktop and then some extra apis but you know i think it's always good to reiterate with react native that it is not about writing once and deploying everywhere but uh about uh learning ones and writing everywhere so um this is similar in the case that you will have to put in some care to make an application on the desktop feel like a desktop application which i think is what the users deserve right um for me at commerce we had some really native products our first product is about really native windows on wpf platform is not maintained at all because we we have to support windows 7 and being the first renegade product on desktop ui we we find it has some fundamental differences between mobile and desktop and i find it's uh it is not covered in relative yet for example in um a desktop ui you have touchable you used to have some mouse over feedback and you also have to support drag and drop and multi-window support how about if we could
support multi-window in also the decorative ways such as you have some app and we have a window one window tool and below there are multiple views also i think the desktop is not also covered from renative and we have some ways to do that but in our experience we had a desktop ui and we had a windows platform and we also culture for web and enjoy it as well so we have about 50 percentage culture rate so i think it's really doable for relative renaissance nice that's a very very healthy number i think when it comes to code sharing and i can i just touch on the so it's definitely true obviously that things are still up in the air um but when it comes to for instance these uh pointer uh like mouse events what not touchable we are actually currently in the process of working with facebook both for um the mobile platforms and for the react native web platform and for taking into account mac os and windows how to best provide a a cross-platform api that works for all those yeah if i recon if i recon this uh there i think there is a discussion proposals issue or pr about that where it tries to kind of uh propose a uh standardized approach to handling these things i i think i've seen it before uh and it and it's kind of aligned with what you're saying so might be interesting if i find it out it will include the podcast for those of you who are interested in following up on this um on this topic i also wanted to like upload this discussion a little bit i think while we've been focused on mostly on react native because i understand that
the audience here is about react native i think uh uploading this and talking about react platforms as a principle is also pretty interesting because even in the react world people have been writing custom renderers forever this existed even before react native itself as a platform for example we have had like some really good demos from like ken wheeler on on react music for example or even nicholas on the react native web then i wrote a render around like react web workers which is pretty much react native react 360 is actually like reactive in in like a 360 environment so i think we've been having this discussion around the principles of uh up leveling it and calling it a react platform and i think this is a blog post that eli published some time ago on the react native blog where he talks about the concept of hey the fact that react itself is a declarative ui pattern kind of lends to this idea of adding multiple platforms so with that in mind if we were to upload this discussion the way i see it is react would be the top level root node and then things like react arm reactive windows reactive android will all be siblings all of them adding different levels of abstraction where you get hey maybe the data fetching relay or the graphql components can be the same but all you care about is the leaf node components that are different i also want to be very very uh i want to ensure that we also understand that it's very critical to embrace the platform just because we are sharing code does not mean that we give up on the ios specific interactions or android specific interactions so i think as people are thinking about code sharing it's critical to ensure that your app
looks and behaves like a network and i think that's the biggest promise that reaction brings to you yeah great great really great point i think that's one of the one of the reasons why a lot of react native applications are performing and looking better than you know typical hybrid approach is just because react native has been always about embracing the platform and it kind of brings us really nicely which is a surprise to the next question which is about flutter which takes slightly different approach and we've seen a great kudos talk on you know how we can render react native components potentially to kia which which brings us very close to what flutter potentially is and and you know there there has been a lot of uh developers talking about flutter being superior because of being synchronous and and and this is getting also how kind of outdated as we are getting into the new architecture react native so my question is do you think this and i'm talking about uh that this kind of ski render potentially and this synchronous axis is kind of an interesting achievement for the flutter community and and and would would it make react native a sort of interesting alternative and choice for them uh what do you think about that um i heard some some people like the flood because they don't like javascript okay i don't have comments for that and i don't think renee sukiya will in inspire lame so for me a real native ski is also my self-change to learn more about fabric and i also want to prove that renative could extend to another different platform such as flutter and the project current state is uh still
far from production because we still need some critical critical parts such as capacitor because we want to draw each draw each view in our own so but we have some community to do this project so maybe it will be possible to to being a true prodder and i would like to borrow some call from flutter so maybe the project will be relative flutter that'll be that'll be good connection of very great keywords uh from the you know search engine perspective i think uh rob maybe you want to kind of chime in from the um uh synchronous asynchronous perspective because i i know you've been always very you know passionate about these aspects of performance so kind of interesting interesting to see your perspective on that as well uh so i'm actually a pretty huge fan of flutter and i think the people who have developed clutter have like uh the architecture that they've come up with like pretty interesting in fact if you think about it reacted has always been about questioning our assumption and looking at how we can stretch the envelope i think flutter does exactly that and flutters primary uh hypothesis is that hey why do you need all of these different rendering layers in android if you can just go directly drive to the gl layer or directly right to the graphic system right and that's what makes like flutter great because basically what you do is your dart commands are taken and written to flutter and it does it in a synchronous way now uh that's what that's one of the really interesting things that flutter offers and i think
kudos experiment with react native is a very good way to figure out how can we combine the ease of development in terms of like declarative ui so some of the good things about react is that it's easy to reason about the ui is declarative with things like hooks you know that hey this is the functional part of it versus this is the part where i have a side effect on my component stuff like that so this whole developer friendly developer mindset is taken to the performance area where you're like hey now that i've taken care of developer developer developer experience let me also take care of user experience so i think it's a pretty good exploration uh i'm not a great fan of like comparing react native versus splatter i know that the javascript community kind of likes drama and tries to say which one is better uh personally i think that there is like really good things in both react native and flutter and we are we are starting to learn from each other so well so in terms of performance i think like i'm super excited about this whole idea of synchronous and it's not about like synchronous versus asynchronous uh we are now coming to a world that we have realized that both of them are equally important if you want to respond quickly to user actions you need to be you need to draw synchronously on the other hand if something you're waiting for from a network takes you a second adding 100 100 millisecond delay is not going to like prevent you from anything so this whole idea of synthesis and asynchronous as and when needed to ensure that your focus is on user experience i think that's that's what excites me about like this whole idea of like
react native skier and doing it in the simplest way yeah i i would like to echo that it is a little bit of apples and oranges they are not necessarily the same thing um and there's obviously always trade-offs involved uh if you if you want to reliably build for multiple platforms with a single code base with less with thinking a little less about the specific platform intrinsic details then that is that that that seems more of a case for flutter than it is react native but react native as i've said and rum also said we always want people to actually put in the extra work to make sure that an application is absolutely adheres to the the design guidelines that go into a platform if i were to build an application and i would have the i would not need to think about constraints such as like immediately deployed to all these platforms then that would probably be a reason for me to stick with react native because i really like using those native uis um rather than custom drawn ones um also and i'm not familiar in like there's no need for me to use a flutter so i haven't used the data but uh i actually quite like with react native how there's a kind of a hard constraint between the the ui code um and some of the native aspects where with if you are where with our older objective-c applications it's you know over time in terms of maintain maintenance it just is always a little easy to do something something a little easier where you access code that should be accessed from a different thread in a different place um and i like with react native how
that's just you have to write a little bit of a boundary thing which makes you think about that and keeps them separate more um so i i'm not necessarily looking for a solution where i can do everything natively from a different language that's that's how some people view it i would say yeah that makes a lot of sense and actually uh when you were when you were when you were mentioning well since you brought that up uh it reminded me of uh of an interesting uh use cases that uh i know i know uh i know one of the leading automotive companies has they are essentially just using flutter for kind of developing for their custom hardware and what they are using is they are just able to kind of back flutter directly into your hardware and just have it as a sort of native language let's say so for them it perfectly makes sense they can just make it run natively so it makes me really really you know unhappy because that brand is you know one of my top favorites and i i wish they were using react native but um looks like i might need to change my brand then but anyway um uh the last card yeah yeah you know always there's always a conclusion about cars at the end of the day um as you can see behind me um but um going to the next question actually uh eloy that's the one i guess for you but i i'm pretty sure that others might have some interesting insights here as well from the open source perspective and we briefly talked about it before uh in terms of how do you maintain your fork your platform when you have to keep your code in sync with the master
and uh what i specifically would like to understand about it is how do you backport some of the features so say uh code gen lands uh or is kind of turned on by default how do you make sure that you know these features work with your fork do you have some sort of special thinking mechanism or is it a very very hard manual painful work i just you know would be great to understand how hard or how easy this might be for you on a daily basis yes it would be really great to understand that's that is basically it there's a gradient of uh solutions when i look at what we have at microsoft which is react native mac os windows but then also we have you know some specific patches for instance for android um there's a few different systems like react native windows is most in sync right now react native mac os is most out of sync um reg native mac os currently just means you know pulling all the changes from right that's what i'm doing right now from point 63 and then reapply and emerging all our forked uh changes and and the four changes are literally just you know because ios and macos code in many cases is so similar uh but it is not that easy to have them neatly factored out you know they are in line with a lot of if depths and luckily there's a lot of comments that demark those places uh but it is a very manual process the android one and also the windows one actually is a little different where they main where they've extracted all these fork changes into a set of patches that is reapplied um automatically whenever the
upstream changes are pulled but just also because mac os uh the windows version has a a little more budget uh there's just people that are able to pull more on like a weekly basis and it makes the whole thing maintainable that doesn't mean that necessarily all features are used from upstream as is right so well for instance at microsoft obviously we use a lot of typescript instead of flow so the whole uh code gen aspect uh we have a different uh parser for which generates the intermediate representation that is then used to generate the native code um and then we also have currently in the windows version as that's being ported to the macos version a slightly different turbo modules api um but we're also in talks with facebook to see if we can reconcile that back up stream so you know it goes it goes in all directions that doesn't necessarily always make it the easiest thing uh but as we're working throughout it it over time it becomes clear like how the future could look like four out of three platforms at some point um possibly ios and android could be considered uh treated the same way as out of three platforms where there's just a core of react native and then there's all the platform-specific implementations and it goes you know as as you know like with the to the cli uh packages uh to the native code and it probably makes it a lot easier that way in the long term to to do these things but right now it is definitely a lot of manual process and figuring out together what should move where um as we try to keep that up to date mac os
is definitely uh yeah like i said it's a little uh lagging behind because of how manual the process is yeah yeah as you said uh you know from the cli perspective we are already kind of doing this by having you know ios 100 uh commands to ship as a separate packages which might be hard to describe here in this podcast but uh all i wanted to say is that you know sometimes i feel like react native was so great from the conceptual perspectives that the variety of out of three platforms were faster to appear than the framework itself was ready for them and i feel like we are working on that right now to make that you know kind of easy for you and other people to integrate with and i'm happy that from the cli perspective we are doing small changes but i'm also kind of excited about the you know deep uh the um this structure is destructuring of react native into smaller packages i think there's somebody working on that as well so um you know exciting times ahead i think for out of three platforms or actually platforms because i think somebody banned use out of three at some point so let's let's not use that i think yeah i think in terms of like the simple example when it comes to abstracting things right it's like so this ios and mac os shared code that would likely be a shared package that is apple or whatever apple code um and and then there would be an ios out of three or and now ios platform implementation and then macos implementation that both rely on the shared one and the same i imagine would happen with cli packages
yeah so uh i think that's a great time to wrap up this uh sort of multi-platform part of our of our uh panel and as i said looks like we have exciting times up ahead i i can't wait for actually trying out uh macas reg native and and actually try and get windows again um back in the day i only tried c sharp or c plus plus and you know that didn't turn out really well so it might be a good time so uh the last section with just a few basic questions about general react native development you know we can talk about new architecture we can talk about multi-platform but at the end of the day we all create some kind of react native code and we solve some maybe challenging or typical daily problems with react native uh so uh maybe we can start with that one uh what was the biggest or the latest performance challenger that you have faced at your job and how did you solve that and what were the takeaways from it we can start with ram uh yeah i was running i mean it's performance there's no reason i wouldn't take it so uh i'm going to react to the performance part i think uh and this is also what prompted me to do the talk and react with the eu i think uh uh the mistake i made was i kind of like uh was talking about like native performance and improving native performance over and over again but one of the things that i realized is that there's also a ton of like performance issues in the javascript side of the world so the latest performance issue that i had was around like javascript thread being super busy and as you know you can expand many
threads on the native side there are a lot of solutions there but on javascript there is not much and if you need a thread if your javascript thread is busy if you click a button it shows like you can actually see that the javascript button click does not go through and i was trying to understand like what happens and i think the to your question about what is the perform uh the issue the issue was the javascript thread was slow and i had no clue how to solve it i also discovered that the javascript profilers used to work with jse and are broken on hermes and we have an internal tool that we were able to use to like get the sampling profiler running that's when i also realized that there's nothing exists in the open source and luckily for me we had the mlh fellowship program which is the which is a program to bring in new students and new contributors into reactive and get them to build stuff i was actually super lucky to get into that that the project got accepted into mlh and we had two really talented students build the visualization for the hermes sampling provider open source so i'm hoping that if i if yeah just like me if people are also figure facing like issues with javascript performance that's one tool that will come in handy that people can build okay people can use and build nice and by the way ram i have to say here that recently i've been uh working on the startup performance of my android app and i have i had an issue with react markers and systrace and i found some articles of yours you know describing how to set it up with some kind of custom code hosted on gist how to make it work and i was just you know so glad that you did it did the hard
work before because it was such a time saver so i just want to thank you uh for doing this as we are you know talking about performance right now um right uh monica i think you wanted to say something as well about about the the challenge that you had major league soccer you're working a product i think so uh there might be some interesting uh problems that you are facing every day yeah um there are actually multiple performance um you know gaps and challenges that we are faced with all the time but the one that i um when i was thinking about this question um that came out to my mind because it's like i guess the most challenging that we have had in the recent time uh has been our massive upgrade of our app uh we were you know just like trying to um migrate to under yeah and android dex which again it sounds like to be something way behind but because we have a lot of like libraries that we depend on and like so much of like native code uh we were just recently doing it um and then after doing this just the upgrading of some of our major libraries like react navigation for instance uh made the process of migrating overall uh very challenging uh especially because we had some libraries that were already considered legacy code and had kind of like changed everything internally so um this particular particularly forced us to um think about ways to solve issues like total incompatibility in compatibility with the new apis right so like the whole process which led us to uh have uh great
increases in performance was uh you know definitely something that every person who is developing a native um always has to face and i think it was important to bring it up here because we also face it at uh mls having a bunch of interviews working on it and just being an app that we have developed for uh quite a long time already yeah yeah totally agree and actually this i think uh brings brings me to the next question which i can ask you as well as a follow-up uh from the migration perspective um because there is a lot of there's a lot of a lot of companies you know are migrating to react native right now from variety of different apps uh small ones and big ones one platform many platforms and um they are also trying to transition from native developers to javascript developers which is also a challenge on its own so i guess um my question would be what would be the biggest challenge that you would say might be here and and and and what would be the advice for somebody who's looking to start doing this as we speak and you mean to start like building up um real native applications yeah just trying to migrate uh from the existing apps to read native so you say you have like two or maybe like you have an app native app and you're about to migrate it uh so that that's a intermediate brownfield app that's eventually gonna be greenfield uh hopefully when they are ready oh there are many things that we have to take into account but i think uh you know dividing the process in chunks is perhaps the most the smartest thing to do
as well as uh determining compatibility from the libraries and like all of the parts of your app uh with uh in this case react native but everything that we're trying to develop sometimes and we what we have found out so far is like of course black native is amazing and we love working with it but you know there are things that are still we need to type kind of like tweak and move around so we are compatible with some of the libraries for third-party providers that are not working with a react native mind and then this kind of goes with uh what graham and um cuda were talking before about like you know they don't and i guess everybody they're not um all the libraries are not just like the same thing competing for the same and and rather languages as well um you know just like so i guess understanding um what are the limitations and capabilities of like the libraries that you have on the native native side and then uh what are the limitations and capabilities that react native offers is like a perfect starting point for everything yeah i i would agree definitely with that when we started converting the rc app i think for a lot of people it is very tempting to want to think about javascriptifying all of it as soon as possible but you know that i would say that that is not really necessary and uh you can probably focus on other things first also you know there's there's some cases where you depending on the the company where you will want to keep native code anyways and which actually you know that this this conference this conversion the rcap
is so long ago that i don't know how much it really applies to technically to companies nowadays actually that is my react native eu talk about so you can just look that up on youtube but it's more interesting i think i don't know if you were point hinting at that mike but obviously it's not just a technological thing right it's it's working with with people with developers um i've had many conversations with companies where they are where they tried or they consider introducing react native and we actually oh not now that we're talking about it actually remember uh from our cpu people did a conference at facebook a small conference uh which is art c x react native on youtube and my colleague maxime did a great talk about learning how to learn which is more about the psychology of developers that and and considering that aspect as she was um you know when when i introduced react native and how i did not necessarily uh truly uh considered all of the aspects how that you know how that affects a native engineer how they suddenly are dropped into something new how their specific skills are or how do they fit in i think in the end um you know for at artsy that was a good mix where we now have the ability to have a lot more people working more product teams working on the application but we definitely always try to embed a native expert into each of these teams to ensure that we have the quality that we're looking for but it definitely it's not something that you can just take for granted or just consider like oh yeah it's easy win budget wise let's just switch to javascript that's
probably a recipe for disaster if you have a larger team of native developers right yeah i i totally agree with that as well actually this is something that we run many times when we are working with you know clients they're about to do this transition technology is one thing but then trying to kind of get into the existing organization where there are native developers different teams prefers you have to sell them react native as well and kind of demonstrate the benefits of that and this becomes a challenging task on its own so i guess as soon as everybody's on board you can say that you have some kind of success already uh achieved um yeah uh cool so i think you know that's that's it from the questions that uh we have received from the react native eu obviously there is still a lot of questions that we had i think we had more than 100 and i decided to group them into smaller uh talk oriented questions and every speaker received them in an email so we will be working on them and they follow up and and you know if we were about to answer one 100 questions here we would probably have to spend the whole day um which would be impossible given the time zone differences we have here uh so so uh so i guess you know that that brings us to the to that so to the end of our panel and i wanted to thank you very much for joining and i know that you are all from different places from the world so we have you know some we have ram uh where it's 7 a.
m or 8 a.
m right now kuda that's probably like just minutes before midnight and and and the rest of us is kind of somewhere in between
m or 8 a.
m right now kuda that's probably like just minutes before midnight and and and the rest of us is kind of somewhere in between
so it's been a really challenging thing to pull off and i'm really happy that we made it so all i wanted to say is thank you for you know taking part in this podcast i hope that you liked it and um and yeah just just thank you for for being part of this and i'm looking forward to seeing you um again uh maybe on a podcast as well awesome thank you mike looking forward to seeing you all again as well and perhaps consider still some online s components even if at some point conferences do go live again yeah well um for for what it's worth i think you know uh one thing is that we've been recently talking together a lot because we are working on some crazy stuff so i'm hoping that you know we might have some programming like this more often rather than just talking because you know it always makes me happy uh to see faces and to speak with developers because we kind of write 99 percent of time and then it is so stressful experience for me to talk with you because you know we we don't talk often like we usually write so uh there's a lot of you know um sort of uh information coming like the face the smile the the the gestures so it's pretty fun experience but uh yeah we should do it more often for sure okay thank you once again and uh hoping to see you again really soon
Timestamps
Show
Guests
No items found.
welcome everybody to the next react native uh show podcast today we have a special edition which is also a react native eu panel and today with me we have very special guests that will be answering some of the most interesting questions that you have been asking during the react native conference so maybe let's do a quick introduction of every guest starting from my left side so i guess the first person to go with eli eli if you could introduce yourself what are you doing at your day job what are you doing with react native on a daily basis and essentially everything that you'd like our listeners to know about you oh that's an interesting question mike um so i'm eloy i currently work at microsoft um and i work on their react native needs in office um which day-to-day means that i'm working on getting mac os react native uh up to speed with the other um versions that exist um and also helping out the community with some things like uh getting the releases out etc otherwise let's see i've yeah i worked on cocoapods dependency manager and the ios mac os space so i have a lot of int i've always had a lot of interest in the where native meets scripting other languages um and that's how i found my way to react native when i worked at artsy interesting yeah i i seen a couple of your recent pr's around native code i'm not gonna spoil that word because there is some exciting stuff coming up so we'll probably learn about that in the nearest future thank you for that so the next person is paroshuram ram now it's your time hey everyone my name is ram i'm an engineering manager at facebook
and i'm currently working in oculus oculus if you haven't heard is the virtual reality reality headset that uh facebook produces and at oculus i'm mostly working on uh react and reactive based 3d systems for uh 2d systems for a 3d environment before this i used to be on the react native team where i was working on the re-architecture of the application specifically on turbo modules and have done a lot of work on performance uh i've actually been associated with react native even before i was at facebook before facebook i was at microsoft and if you folks remember code push i was a pm on codepush trying to like help people push their code faster and i also helped build the vs code plugin for react native building mobile applications for ios and android using javascript is something that's always near and dear to my heart in fact i'm also a apache core committee member of the apache cordova project or more commonly known as phonegap project and during my time at microsoft i've done xamarin so as you can see i like played around with all the technologies which is not java and objective c that you can use to build mobile applications that's me that's really exciting and i think uh when i think about the first time we met i think that was in a conference uh in us when you were when we were talking about code push actually that was back when you were in microsoft that's been quite exciting times when you know coldproof was just starting so uh that's been quite a while ago now i think okay uh thank you thank you so uh the next speaker is monica uh monica if you could tell us a few
words about yourself and what you are doing uh with react native on a daily basis sure uh hi all so my name is monika um i'm a software engineer at major league soccer and i'm currently working in a few exciting projects within the league but mostly focusing a lot in mobile development with our mls app um our app is what we call a hybrid app but but about 70 percent of it is built in react native and then the rest uh swift and kotlin and um that's what i how i use my time at work nice um that's that's that's pretty exciting and how do you like kotlin compared to java what i like about it is the automatic conversion when you copy and paste the stuff to the jetbrains editor that's a real killer feature yeah okay thank you about this uh so uh the next and the last guest on our podcast today is kudo kudo if you could tell us a few words about yourself that would be awesome okay hello i'm kudo i'm a software engineer of clamosa uh day job is about development of browser so i'm really a part-time job for part-time for real native because my day job totally not related to real native at all for the part time i have some side projects such as real native v8 and i also previous a javascript core antenna and this time i have a really native skier so and from the deja i got most familiar with chromium core best because we are doing browser based on chromium so i got a lot of them are familiar with chromium copies that's why i do ba or skia splatter as well nice nice that's that's really exciting and um i think i already said that during
the conference but uh when we met for the first time i i remember your messages in those you know c plus plus related channels on the discord community uh that's been always blowing my mind for a while i even thought that you were working at facebook because the amount of comments about turbo modules made me think that you are maybe actually working on that and then it turned out you are actually an external contributor so uh respect for for for that um all right so uh thank you for introducing as you can see we have a really really great i guess today to talk about react native so maybe let's start with a react native eu question uh how did you like the conference what was the most uh exciting thing about the conference that you liked so far and um we can start from eli first hey i well i really liked that it was online of course as you know i am always a remote and also i i think wasn't it react the first react native eu that i broke my uh um i was on i was i stopped doing any conferences and then i figured like okay well i'll do this yeah i was proud of myself that i can't convince you yeah yeah so i i really like uh not having to travel and do it remotely so i think that was definitely the upside part for me um the talks that stood out to me and that wasn't necessarily one that actually that stood out the most to me i just really enjoy hearing other people talk about react native um um because as you know i work alone here in the netherlands and it is it is fun to have these people talk i enjoy being at the conference talking with people about what they're doing day to day
and that's what i enjoy most about the conferences and having this conference around the this technology that is so exciting to me um so i think that's the most the best part to me awesome who wants to go next i'll go um well i have to go with the lies as well opinion and um it was amazing that it was an online conference um you know having the idea of having people from all over the world just like being able to participate was very interesting i really enjoyed the quality and technicality of all the talks um if i were to pick my favorite i think i'll go perhaps with modernizing react native's javascript by um the us eli as well white i can't remember how to pronounce his name but i'm sorry for that um yeah so i love um i just really love you know like one of the reasons why i go to these conferences is just uh to look for some deep dives into complex relevant topics um and i think this is uh something that this talk in particular did um you know um his talk was really descriptive uh easy to digest and definitely just enlighten any many things so um i'll just pick that awesome ram or kudo i can probably go next i think one of my favorite things about conferences is i usually don't attend conferences for the talks themselves but for meeting people i think like most conferences have talks recorded and posted online but it's that whole connection that you have with your fellow developers who working on like similar problems trying to listen to them and figure out how what kind of similar problems you have that that has been something that's always been like uh of interest and honestly when like
mike pitched this whole idea of hey we're going to do a reactive you i was a little skeptical to start off with i was not sure if it's going to have the same like essence of the conference uh i should say that i was pleasantly surprised in fact uh it was super it was like very interesting to see how on the slack channel people were talking to each other and there was like this whole set of like side conversations that were happening people helping out each other so i can actually say that i did feel that sense of community and honestly react native is a very inclusive and welcoming community and this the slack channel was an embodiment of that uh also i don't know if many people who watch react native eu know this but mike i'm probably going to let out a secret the talks were all recorded they were not actually happening online so that did relieve a good pressure from the speakers and i think what happened was that effectively freda freed the speakers up and helped them answer the questions as the questions were popping up during the uh during the talk so like the slack was super active and the whole community building was was my favorite part about reacting to vu online yeah and i i have to totally agree with you at that point you know usually we are super stressed when it comes to organizing this conference here in roswell but because you know some some of the stuff was already prepared up front we were able to also have slightly less uh i would say intense time during that week so definitely something that uh we will be you know missing from the next year if if it's gonna be happening on site
um cool kudo what about you uh for me i like the topic because there is a diversity from architecture from javascript day-to-day development graphql and about the animation for me i like the animation topic them very well especially inspire me for the animation differences between web and mobile that is really inspirational topic and i also think you think to the conference about the it's a virtual virtual camp because i used to stay with my family and with this chance i could have a talking this year yeah i think we even talked last year when i tried to convince you to submit a cfp and you said traveling will be impossible and this year you know it was finally possible so really really really happy that we made it uh all right uh all right so we are warmed up we are ready to dive deep into the first group uh so just for the record i have grouped uh the questions into three groups uh and these groups are at the new architecture of react native multiple platforms and general development so just general questions uh that people were interested to have answers for uh so let's move on to the new architecture of react native so just to quickly recap last year react native team announced a lot of changes uh to the core of react native that you know addresses a lot of challenges we're facing when it comes down to building applications and that includes turbo modules which is a new implementation of native modules for better performance on synchronous access code gen to ease creation of native modules by synchronizing the type definitions and missile declarations between native and javascript
gsi which is javascript interface and it is a unified lightweight sort of general purpose api for any javascript virtual machine and it enables every uh other piece of the re-architecture and is what for example makes hermes integration very easy and you know easy is obviously really relative here um and then fabric which is just the ui re-architecture to take full advantage of you know these features and concurrent react architecture so while this work is still in progress we can see a lot of these already in the open source and i think it would be great uh to to sort of go over the latest updates than the ria and i think that questions uh from our audience might be a great starting point uh to our discussion so uh so the first question that i have here is you know what is the status of the re-architecture and what are the changes that are already shipped and when do we expect to have an update on the rest of them and i think the best person here would be ram that is you know even wearing facebook t-shirts so uh that tells uh tells it all sure so i think this has been a question that people have been asking and uh i can clearly see how people can't wait to get their hands on uh like the new architecture but i want to be like amply careful here about talking about like there is no release for the new architecture in the sense that there will not be one single date where it's like things stop and like suddenly react natives which switches over to the new architecture uh our initial plan was definitely trying to get it out in 2020 but unfortunately coveted a lot of people their productivity kind of went down and
as a result we may not be able to hit 2020.
uh we are looking at 2021 as something that uh where this can get out but i mean i don't have a specific date in mind but let me also lay down what what does releasing it really mean so uh let me talk about a little bit on what what's happening in terms of how how fast you're going internally and then talk about what's available externally so internally i think on the main facebook app we are actually testing fabric we are testing our turbo modules and honestly jsi is pretty much the way to go for both fabric and turbo module all of our native modules are code giant in fact we also retro cogent the existing modules there's like turbo modules tech and stuff for existing modules also so the testing is heavily underway we are seeing some really exciting results both in terms of performance and in terms of stability and i think one of our biggest motivations here is to ensure that the transit transition is smooth and stable more importantly like people's apps don't start crashing and that's why we are being exceedingly careful we've also started to roll out fabric and turbo modules to internal apps for example the oculus companion app that i work on we are starting to roll out turbo modules in it fabric is a little bit harder because we wanted to do it screen by screen and for that you need native navigation which we are trying to move to uh and this is a similar story with all standalone applications so i think the best way to think about it is internally in facebook apps we are slowly starting to roll out fabric and tower modules uh
uh we are looking at 2021 as something that uh where this can get out but i mean i don't have a specific date in mind but let me also lay down what what does releasing it really mean so uh let me talk about a little bit on what what's happening in terms of how how fast you're going internally and then talk about what's available externally so internally i think on the main facebook app we are actually testing fabric we are testing our turbo modules and honestly jsi is pretty much the way to go for both fabric and turbo module all of our native modules are code giant in fact we also retro cogent the existing modules there's like turbo modules tech and stuff for existing modules also so the testing is heavily underway we are seeing some really exciting results both in terms of performance and in terms of stability and i think one of our biggest motivations here is to ensure that the transit transition is smooth and stable more importantly like people's apps don't start crashing and that's why we are being exceedingly careful we've also started to roll out fabric and turbo modules to internal apps for example the oculus companion app that i work on we are starting to roll out turbo modules in it fabric is a little bit harder because we wanted to do it screen by screen and for that you need native navigation which we are trying to move to uh and this is a similar story with all standalone applications so i think the best way to think about it is internally in facebook apps we are slowly starting to roll out fabric and tower modules uh
like ironing out the issues and any uh edge cases that we encounter as far as open source is concerned uh you'd actually be surprised but both fabric and turbo modules are out there i think the biggest challenge is it's not buildable and that's only because facebook internally uses buck so all of our build scripts are reliant on bug now this is where i think we can use some help from the community and i think someone did this for ios where they picked up the ios turbo modules and fabric systems wired it up into the xcode build and they were able to build it we haven't done that on gradle yet so if someone is brave enough and wants to try this out i would like to recommend this as a really good project where you play around with gradle and enable like a turbo modules and fabric on rn tester for example uh it's not as hard as it looks it's basically a bunch of magic around graded scripts and android dot mk the c plus plus wrapper so that's the current state of the world a lot of codes out there i think eli also spoke about like code generation and uh i think it is in a state where you can try it out test it out but i'm not sure if i would recommend it for production yet mostly because it's not officially supported yeah yeah yeah yeah uh thanks for answering that and actually you would be surprised that i i mean i'm not i'm not surprised because i've been there already how how quickly sometimes it might be how easy it sometimes might be to to kind of release some of these internal pieces into into react native for ios for example on the on the hermes side uh compiling it for ios is theoretically just you know
doing some changes to the cmake which on h1 is very hard but i was kind of surprised that you know essentially the code is just c plus plus so as long as you compile it it theoretically can run so not a lot of magic there inside uh as someone would think um awesome so um so that brings me to the next question where where i could track the progress of that uh in the future for example uh so i think monica also wanted to answer this but let me quickly give a feel of like the discussions repository and the history which i probably haven't spoken about so i think almost one year ago when i was in react native team i realized that there was a lot of discussions that were happening one-off and one of our our goals in the react native team was to be inclusive and ensure that every discussion is transparent and people understand the rationale band what's happening that's the reason why we created this repository called discussions and proposals where people like anyone in the world can submit a proposal people can critique it look at look at what can be implemented and then go ahead and implement it so we have this proposal called discussions and proposals and uh there's a there are issues related specifically to turbo modules and to a fabric uh that's where most of our updates are happening unfortunately those issues could also be noisy because usually for every single update there's like 10 comments asking hey when is it ready uh so you might want to you want to you might want to add on your noise filtering in there but i think those are probably the best places that you can look at it's also a place where i'd recommend if
you're experimenting with turbo modules for example just go add your status there and tell people hey here's what i've tried out and people might come asking you i think also that um if you allow me to jump in in addition to what ram just said uh intuitively the first place that i a particular go and i will recommend people who are just getting into is um of course the react native repo where we also have like a bunch of like issues being discussed and the react native community repo in particular with the react native community repo i found it very useful especially their releases uh section um i believe and correct me ram if i'm wrong it's like one of the most reliable places to go um you know in regards of staying up to date with uh status reports and and you know uh all what's going on um with react native overall um and then just the usual just chain logs and then release notes from uh from your team at facebook i think it's also um yeah just like tracking all those will be pretty effective in just keeping um you know any developer up to date cool uh so so what is the feature you're most excited about um i don't know what you're asking me okay so these well we've been talking about how big this new re-architecture of react nato would be or is like kind of the process of being and of course there are a lot of things that will be definitely um game changers um and the way we develop apps but if i have to pick one i'm definitely gonna go with turbo modules um you know this new feature that pretty much tackles um
you know the most in terms of performance and safety and um i really like the idea of having tape safety between native uh code and javascript and uh particularly for uh particularly for us at mls this is really important because we we do have a fair amount of native modules and integrations um with uh third-party providers so um you know the overhead reduction that turbo modules introduces when calling methods from the javascript side is something that is really really going to help us with performance um you know among with the faster startup when initializing our application so definitely turbo module for me nice i like that i like that as well anybody else want to chime in here uh for me it's probably going to be jsi uh because gsi is like the fundamental layer that's the on which all of these things are built and you'd actually be surprised but all the other hybrid mobile app development platforms have a story similar to uh jsi for example if you look at native script native script actually has a way to generate all of these javascript files based on templates like you take a java class it automatically generates all the methods and exposes them to javascript and the mechanism they use is something very very similar similar to jsi in fact jsi is also fundamentally the way a browser exposes its native apis to your javascript player so looking at it in retrospect maybe we didn't really need a bridge back then and we could have just used gsa but uh i would like vote for jsi mostly because it's like the founding block
of the foundation of the entire system and js is also already ready so you can technically start using gesso right away not just for fabric whatever modules but even let's say you're building your own uh javascript layer on top of a javascript engine jso would come in very handy yeah i i'm uh probably most excited about uh fabric um ever since initially when we explored uh react native at artsy i think i spent a month trying to just get react native to work with ui kit as i was used to it um and things like uh i don't know a ui collection view or all those sorts which with the artsy app you know there's so many images shown and you want to have fast scrolling and fast interactions that that was kind of just uh it felt like a necessity in the end i think the app works works really well with jag native as it is but you know conceptually i think having the ability to do such a synchronous ui work will probably pay off in in in areas where it is noticeable that react native is somewhat lacking for me i also like the fabric of your more excited about fabric as well from my talk i said that uh for third party development developer to have a out of three platform is really really a disaster because the upstream changes really change every day and so for especially for the individuals it's really hard to have out of three platform and now with the fabric most of core is also cross-platform so i think it will benefit for the new platform and method is possible yeah i i totally agree with that and i think that brings us to the next section which is kind of related to multi-platform uh
react native so react native running on other platforms and at the end of the day uh everybody who's been ever maintaining a separate regulative fork has been running through that kind of problem that you have mentioned so um so so from the very beginning react native was obviously about cross platform and while it shipped only with ios and android or i think the android was actually added a few months later um everybody knew that you know other platforms are eventually just a matter of time when somebody will start working on them and this year we've seen a lot of great contributions from our partners in the community including microsoft on additional platforms such as you know windows and surprisingly mac os and and we have received a lot of you know questions from our audience on that aspect and in the general direction of the framework in that area so i think we can start off with a question with the first question which is uh which is which is um uh kind of about sharing the code between mobile and web so with the new platforms being released and becoming production ready uh what opportunities do you envision when it comes to sharing code between mobile and web traditional react and react native targets and desktop environments do these have a lot or something in common uh and i think uh like maybe you want to start as you're representing actually uh the the microsoft here as well uh and you are working on uh windows and mac os parts of real native yeah well so i think um you know clearly any code that is not
necessarily ui related or particularly dependent on the os will be easily shared as plain javascript um so that is definitely already a win i think i can imagine like if i take the rt app as an example porting it to desktop means that all the the data layer would would just work um so the piece and then when it comes to the ui large pieces of the ui would work i think people are familiar with catalyst it would be somewhat similar to that you are able to leverage most of the ui but obviously there are some paradigms that you only have on desktop and then some extra apis but you know i think it's always good to reiterate with react native that it is not about writing once and deploying everywhere but uh about uh learning ones and writing everywhere so um this is similar in the case that you will have to put in some care to make an application on the desktop feel like a desktop application which i think is what the users deserve right um for me at commerce we had some really native products our first product is about really native windows on wpf platform is not maintained at all because we we have to support windows 7 and being the first renegade product on desktop ui we we find it has some fundamental differences between mobile and desktop and i find it's uh it is not covered in relative yet for example in um a desktop ui you have touchable you used to have some mouse over feedback and you also have to support drag and drop and multi-window support how about if we could
support multi-window in also the decorative ways such as you have some app and we have a window one window tool and below there are multiple views also i think the desktop is not also covered from renative and we have some ways to do that but in our experience we had a desktop ui and we had a windows platform and we also culture for web and enjoy it as well so we have about 50 percentage culture rate so i think it's really doable for relative renaissance nice that's a very very healthy number i think when it comes to code sharing and i can i just touch on the so it's definitely true obviously that things are still up in the air um but when it comes to for instance these uh pointer uh like mouse events what not touchable we are actually currently in the process of working with facebook both for um the mobile platforms and for the react native web platform and for taking into account mac os and windows how to best provide a a cross-platform api that works for all those yeah if i recon if i recon this uh there i think there is a discussion proposals issue or pr about that where it tries to kind of uh propose a uh standardized approach to handling these things i i think i've seen it before uh and it and it's kind of aligned with what you're saying so might be interesting if i find it out it will include the podcast for those of you who are interested in following up on this um on this topic i also wanted to like upload this discussion a little bit i think while we've been focused on mostly on react native because i understand that
the audience here is about react native i think uh uploading this and talking about react platforms as a principle is also pretty interesting because even in the react world people have been writing custom renderers forever this existed even before react native itself as a platform for example we have had like some really good demos from like ken wheeler on on react music for example or even nicholas on the react native web then i wrote a render around like react web workers which is pretty much react native react 360 is actually like reactive in in like a 360 environment so i think we've been having this discussion around the principles of uh up leveling it and calling it a react platform and i think this is a blog post that eli published some time ago on the react native blog where he talks about the concept of hey the fact that react itself is a declarative ui pattern kind of lends to this idea of adding multiple platforms so with that in mind if we were to upload this discussion the way i see it is react would be the top level root node and then things like react arm reactive windows reactive android will all be siblings all of them adding different levels of abstraction where you get hey maybe the data fetching relay or the graphql components can be the same but all you care about is the leaf node components that are different i also want to be very very uh i want to ensure that we also understand that it's very critical to embrace the platform just because we are sharing code does not mean that we give up on the ios specific interactions or android specific interactions so i think as people are thinking about code sharing it's critical to ensure that your app
looks and behaves like a network and i think that's the biggest promise that reaction brings to you yeah great great really great point i think that's one of the one of the reasons why a lot of react native applications are performing and looking better than you know typical hybrid approach is just because react native has been always about embracing the platform and it kind of brings us really nicely which is a surprise to the next question which is about flutter which takes slightly different approach and we've seen a great kudos talk on you know how we can render react native components potentially to kia which which brings us very close to what flutter potentially is and and you know there there has been a lot of uh developers talking about flutter being superior because of being synchronous and and and this is getting also how kind of outdated as we are getting into the new architecture react native so my question is do you think this and i'm talking about uh that this kind of ski render potentially and this synchronous axis is kind of an interesting achievement for the flutter community and and and would would it make react native a sort of interesting alternative and choice for them uh what do you think about that um i heard some some people like the flood because they don't like javascript okay i don't have comments for that and i don't think renee sukiya will in inspire lame so for me a real native ski is also my self-change to learn more about fabric and i also want to prove that renative could extend to another different platform such as flutter and the project current state is uh still
far from production because we still need some critical critical parts such as capacitor because we want to draw each draw each view in our own so but we have some community to do this project so maybe it will be possible to to being a true prodder and i would like to borrow some call from flutter so maybe the project will be relative flutter that'll be that'll be good connection of very great keywords uh from the you know search engine perspective i think uh rob maybe you want to kind of chime in from the um uh synchronous asynchronous perspective because i i know you've been always very you know passionate about these aspects of performance so kind of interesting interesting to see your perspective on that as well uh so i'm actually a pretty huge fan of flutter and i think the people who have developed clutter have like uh the architecture that they've come up with like pretty interesting in fact if you think about it reacted has always been about questioning our assumption and looking at how we can stretch the envelope i think flutter does exactly that and flutters primary uh hypothesis is that hey why do you need all of these different rendering layers in android if you can just go directly drive to the gl layer or directly right to the graphic system right and that's what makes like flutter great because basically what you do is your dart commands are taken and written to flutter and it does it in a synchronous way now uh that's what that's one of the really interesting things that flutter offers and i think
kudos experiment with react native is a very good way to figure out how can we combine the ease of development in terms of like declarative ui so some of the good things about react is that it's easy to reason about the ui is declarative with things like hooks you know that hey this is the functional part of it versus this is the part where i have a side effect on my component stuff like that so this whole developer friendly developer mindset is taken to the performance area where you're like hey now that i've taken care of developer developer developer experience let me also take care of user experience so i think it's a pretty good exploration uh i'm not a great fan of like comparing react native versus splatter i know that the javascript community kind of likes drama and tries to say which one is better uh personally i think that there is like really good things in both react native and flutter and we are we are starting to learn from each other so well so in terms of performance i think like i'm super excited about this whole idea of synchronous and it's not about like synchronous versus asynchronous uh we are now coming to a world that we have realized that both of them are equally important if you want to respond quickly to user actions you need to be you need to draw synchronously on the other hand if something you're waiting for from a network takes you a second adding 100 100 millisecond delay is not going to like prevent you from anything so this whole idea of synthesis and asynchronous as and when needed to ensure that your focus is on user experience i think that's that's what excites me about like this whole idea of like
react native skier and doing it in the simplest way yeah i i would like to echo that it is a little bit of apples and oranges they are not necessarily the same thing um and there's obviously always trade-offs involved uh if you if you want to reliably build for multiple platforms with a single code base with less with thinking a little less about the specific platform intrinsic details then that is that that that seems more of a case for flutter than it is react native but react native as i've said and rum also said we always want people to actually put in the extra work to make sure that an application is absolutely adheres to the the design guidelines that go into a platform if i were to build an application and i would have the i would not need to think about constraints such as like immediately deployed to all these platforms then that would probably be a reason for me to stick with react native because i really like using those native uis um rather than custom drawn ones um also and i'm not familiar in like there's no need for me to use a flutter so i haven't used the data but uh i actually quite like with react native how there's a kind of a hard constraint between the the ui code um and some of the native aspects where with if you are where with our older objective-c applications it's you know over time in terms of maintain maintenance it just is always a little easy to do something something a little easier where you access code that should be accessed from a different thread in a different place um and i like with react native how
that's just you have to write a little bit of a boundary thing which makes you think about that and keeps them separate more um so i i'm not necessarily looking for a solution where i can do everything natively from a different language that's that's how some people view it i would say yeah that makes a lot of sense and actually uh when you were when you were when you were mentioning well since you brought that up uh it reminded me of uh of an interesting uh use cases that uh i know i know uh i know one of the leading automotive companies has they are essentially just using flutter for kind of developing for their custom hardware and what they are using is they are just able to kind of back flutter directly into your hardware and just have it as a sort of native language let's say so for them it perfectly makes sense they can just make it run natively so it makes me really really you know unhappy because that brand is you know one of my top favorites and i i wish they were using react native but um looks like i might need to change my brand then but anyway um uh the last card yeah yeah you know always there's always a conclusion about cars at the end of the day um as you can see behind me um but um going to the next question actually uh eloy that's the one i guess for you but i i'm pretty sure that others might have some interesting insights here as well from the open source perspective and we briefly talked about it before uh in terms of how do you maintain your fork your platform when you have to keep your code in sync with the master
and uh what i specifically would like to understand about it is how do you backport some of the features so say uh code gen lands uh or is kind of turned on by default how do you make sure that you know these features work with your fork do you have some sort of special thinking mechanism or is it a very very hard manual painful work i just you know would be great to understand how hard or how easy this might be for you on a daily basis yes it would be really great to understand that's that is basically it there's a gradient of uh solutions when i look at what we have at microsoft which is react native mac os windows but then also we have you know some specific patches for instance for android um there's a few different systems like react native windows is most in sync right now react native mac os is most out of sync um reg native mac os currently just means you know pulling all the changes from right that's what i'm doing right now from point 63 and then reapply and emerging all our forked uh changes and and the four changes are literally just you know because ios and macos code in many cases is so similar uh but it is not that easy to have them neatly factored out you know they are in line with a lot of if depths and luckily there's a lot of comments that demark those places uh but it is a very manual process the android one and also the windows one actually is a little different where they main where they've extracted all these fork changes into a set of patches that is reapplied um automatically whenever the
upstream changes are pulled but just also because mac os uh the windows version has a a little more budget uh there's just people that are able to pull more on like a weekly basis and it makes the whole thing maintainable that doesn't mean that necessarily all features are used from upstream as is right so well for instance at microsoft obviously we use a lot of typescript instead of flow so the whole uh code gen aspect uh we have a different uh parser for which generates the intermediate representation that is then used to generate the native code um and then we also have currently in the windows version as that's being ported to the macos version a slightly different turbo modules api um but we're also in talks with facebook to see if we can reconcile that back up stream so you know it goes it goes in all directions that doesn't necessarily always make it the easiest thing uh but as we're working throughout it it over time it becomes clear like how the future could look like four out of three platforms at some point um possibly ios and android could be considered uh treated the same way as out of three platforms where there's just a core of react native and then there's all the platform-specific implementations and it goes you know as as you know like with the to the cli uh packages uh to the native code and it probably makes it a lot easier that way in the long term to to do these things but right now it is definitely a lot of manual process and figuring out together what should move where um as we try to keep that up to date mac os
is definitely uh yeah like i said it's a little uh lagging behind because of how manual the process is yeah yeah as you said uh you know from the cli perspective we are already kind of doing this by having you know ios 100 uh commands to ship as a separate packages which might be hard to describe here in this podcast but uh all i wanted to say is that you know sometimes i feel like react native was so great from the conceptual perspectives that the variety of out of three platforms were faster to appear than the framework itself was ready for them and i feel like we are working on that right now to make that you know kind of easy for you and other people to integrate with and i'm happy that from the cli perspective we are doing small changes but i'm also kind of excited about the you know deep uh the um this structure is destructuring of react native into smaller packages i think there's somebody working on that as well so um you know exciting times ahead i think for out of three platforms or actually platforms because i think somebody banned use out of three at some point so let's let's not use that i think yeah i think in terms of like the simple example when it comes to abstracting things right it's like so this ios and mac os shared code that would likely be a shared package that is apple or whatever apple code um and and then there would be an ios out of three or and now ios platform implementation and then macos implementation that both rely on the shared one and the same i imagine would happen with cli packages
yeah so uh i think that's a great time to wrap up this uh sort of multi-platform part of our of our uh panel and as i said looks like we have exciting times up ahead i i can't wait for actually trying out uh macas reg native and and actually try and get windows again um back in the day i only tried c sharp or c plus plus and you know that didn't turn out really well so it might be a good time so uh the last section with just a few basic questions about general react native development you know we can talk about new architecture we can talk about multi-platform but at the end of the day we all create some kind of react native code and we solve some maybe challenging or typical daily problems with react native uh so uh maybe we can start with that one uh what was the biggest or the latest performance challenger that you have faced at your job and how did you solve that and what were the takeaways from it we can start with ram uh yeah i was running i mean it's performance there's no reason i wouldn't take it so uh i'm going to react to the performance part i think uh and this is also what prompted me to do the talk and react with the eu i think uh uh the mistake i made was i kind of like uh was talking about like native performance and improving native performance over and over again but one of the things that i realized is that there's also a ton of like performance issues in the javascript side of the world so the latest performance issue that i had was around like javascript thread being super busy and as you know you can expand many
threads on the native side there are a lot of solutions there but on javascript there is not much and if you need a thread if your javascript thread is busy if you click a button it shows like you can actually see that the javascript button click does not go through and i was trying to understand like what happens and i think the to your question about what is the perform uh the issue the issue was the javascript thread was slow and i had no clue how to solve it i also discovered that the javascript profilers used to work with jse and are broken on hermes and we have an internal tool that we were able to use to like get the sampling profiler running that's when i also realized that there's nothing exists in the open source and luckily for me we had the mlh fellowship program which is the which is a program to bring in new students and new contributors into reactive and get them to build stuff i was actually super lucky to get into that that the project got accepted into mlh and we had two really talented students build the visualization for the hermes sampling provider open source so i'm hoping that if i if yeah just like me if people are also figure facing like issues with javascript performance that's one tool that will come in handy that people can build okay people can use and build nice and by the way ram i have to say here that recently i've been uh working on the startup performance of my android app and i have i had an issue with react markers and systrace and i found some articles of yours you know describing how to set it up with some kind of custom code hosted on gist how to make it work and i was just you know so glad that you did it did the hard
work before because it was such a time saver so i just want to thank you uh for doing this as we are you know talking about performance right now um right uh monica i think you wanted to say something as well about about the the challenge that you had major league soccer you're working a product i think so uh there might be some interesting uh problems that you are facing every day yeah um there are actually multiple performance um you know gaps and challenges that we are faced with all the time but the one that i um when i was thinking about this question um that came out to my mind because it's like i guess the most challenging that we have had in the recent time uh has been our massive upgrade of our app uh we were you know just like trying to um migrate to under yeah and android dex which again it sounds like to be something way behind but because we have a lot of like libraries that we depend on and like so much of like native code uh we were just recently doing it um and then after doing this just the upgrading of some of our major libraries like react navigation for instance uh made the process of migrating overall uh very challenging uh especially because we had some libraries that were already considered legacy code and had kind of like changed everything internally so um this particular particularly forced us to um think about ways to solve issues like total incompatibility in compatibility with the new apis right so like the whole process which led us to uh have uh great
increases in performance was uh you know definitely something that every person who is developing a native um always has to face and i think it was important to bring it up here because we also face it at uh mls having a bunch of interviews working on it and just being an app that we have developed for uh quite a long time already yeah yeah totally agree and actually this i think uh brings brings me to the next question which i can ask you as well as a follow-up uh from the migration perspective um because there is a lot of there's a lot of a lot of companies you know are migrating to react native right now from variety of different apps uh small ones and big ones one platform many platforms and um they are also trying to transition from native developers to javascript developers which is also a challenge on its own so i guess um my question would be what would be the biggest challenge that you would say might be here and and and and what would be the advice for somebody who's looking to start doing this as we speak and you mean to start like building up um real native applications yeah just trying to migrate uh from the existing apps to read native so you say you have like two or maybe like you have an app native app and you're about to migrate it uh so that that's a intermediate brownfield app that's eventually gonna be greenfield uh hopefully when they are ready oh there are many things that we have to take into account but i think uh you know dividing the process in chunks is perhaps the most the smartest thing to do
as well as uh determining compatibility from the libraries and like all of the parts of your app uh with uh in this case react native but everything that we're trying to develop sometimes and we what we have found out so far is like of course black native is amazing and we love working with it but you know there are things that are still we need to type kind of like tweak and move around so we are compatible with some of the libraries for third-party providers that are not working with a react native mind and then this kind of goes with uh what graham and um cuda were talking before about like you know they don't and i guess everybody they're not um all the libraries are not just like the same thing competing for the same and and rather languages as well um you know just like so i guess understanding um what are the limitations and capabilities of like the libraries that you have on the native native side and then uh what are the limitations and capabilities that react native offers is like a perfect starting point for everything yeah i i would agree definitely with that when we started converting the rc app i think for a lot of people it is very tempting to want to think about javascriptifying all of it as soon as possible but you know that i would say that that is not really necessary and uh you can probably focus on other things first also you know there's there's some cases where you depending on the the company where you will want to keep native code anyways and which actually you know that this this conference this conversion the rcap
is so long ago that i don't know how much it really applies to technically to companies nowadays actually that is my react native eu talk about so you can just look that up on youtube but it's more interesting i think i don't know if you were point hinting at that mike but obviously it's not just a technological thing right it's it's working with with people with developers um i've had many conversations with companies where they are where they tried or they consider introducing react native and we actually oh not now that we're talking about it actually remember uh from our cpu people did a conference at facebook a small conference uh which is art c x react native on youtube and my colleague maxime did a great talk about learning how to learn which is more about the psychology of developers that and and considering that aspect as she was um you know when when i introduced react native and how i did not necessarily uh truly uh considered all of the aspects how that you know how that affects a native engineer how they suddenly are dropped into something new how their specific skills are or how do they fit in i think in the end um you know for at artsy that was a good mix where we now have the ability to have a lot more people working more product teams working on the application but we definitely always try to embed a native expert into each of these teams to ensure that we have the quality that we're looking for but it definitely it's not something that you can just take for granted or just consider like oh yeah it's easy win budget wise let's just switch to javascript that's
probably a recipe for disaster if you have a larger team of native developers right yeah i i totally agree with that as well actually this is something that we run many times when we are working with you know clients they're about to do this transition technology is one thing but then trying to kind of get into the existing organization where there are native developers different teams prefers you have to sell them react native as well and kind of demonstrate the benefits of that and this becomes a challenging task on its own so i guess as soon as everybody's on board you can say that you have some kind of success already uh achieved um yeah uh cool so i think you know that's that's it from the questions that uh we have received from the react native eu obviously there is still a lot of questions that we had i think we had more than 100 and i decided to group them into smaller uh talk oriented questions and every speaker received them in an email so we will be working on them and they follow up and and you know if we were about to answer one 100 questions here we would probably have to spend the whole day um which would be impossible given the time zone differences we have here uh so so uh so i guess you know that that brings us to the to that so to the end of our panel and i wanted to thank you very much for joining and i know that you are all from different places from the world so we have you know some we have ram uh where it's 7 a.
m or 8 a.
m right now kuda that's probably like just minutes before midnight and and and the rest of us is kind of somewhere in between
m or 8 a.
m right now kuda that's probably like just minutes before midnight and and and the rest of us is kind of somewhere in between
so it's been a really challenging thing to pull off and i'm really happy that we made it so all i wanted to say is thank you for you know taking part in this podcast i hope that you liked it and um and yeah just just thank you for for being part of this and i'm looking forward to seeing you um again uh maybe on a podcast as well awesome thank you mike looking forward to seeing you all again as well and perhaps consider still some online s components even if at some point conferences do go live again yeah well um for for what it's worth i think you know uh one thing is that we've been recently talking together a lot because we are working on some crazy stuff so i'm hoping that you know we might have some programming like this more often rather than just talking because you know it always makes me happy uh to see faces and to speak with developers because we kind of write 99 percent of time and then it is so stressful experience for me to talk with you because you know we we don't talk often like we usually write so uh there's a lot of you know um sort of uh information coming like the face the smile the the the gestures so it's pretty fun experience but uh yeah we should do it more often for sure okay thank you once again and uh hoping to see you again really soon
Show Transcript
To address the questions from the RNEU 2020 audience, we invited four leading experts to talk about React Native. This episode is a Q&A panel and it’s divided into three parts: the upcoming re-architecture of React Native, its cross-platform compatibility and general development.
The first part covers the new React Native architecture, and Mike and his guest speakers lay out some details on the expected updates and features.
React Native EU 2020 Q&A
Among others, you'll find answers to the following questions:
- What is the status of the re-architecture? What changes are already shipped, and when do we expect to have an update on the rest of them?
- Where can you track updates on the re-architecture?
- Can we expect a smooth transition between current and “new” React Native?
The second part of the podcast explores the multi-platform aspect of React Native. The speakers discuss the opportunities that arise from sharing the same code base between mobile and web. From the very beginning, React Native was all about cross-platform, and with more and more platforms being added, it’s no wonder that this topic sparks a lot of interest.
In the last section, the speakers share their performance challenges. As performance is always a trending topic, we received a great volume of questions concerning best ways to deal with challenging performance issues.
Last but not least, our guest experts give their perspective on the React Native future - the framework development and its general direction.
Facing complex cross-platform challenges?
We help deliver consistent experiences across platforms with one codebase.
Let’s chat
//
Insights
Learn more about
Cross-Platform
Here's everything we published recently on this topic.
//
Cross-Platform
We can help you move
it forward!
At Callstack, we work with companies big and small, pushing React Native everyday.
Code Sharing
Implement effective code-sharing strategies across all platforms to accelerate shipping and reduce code duplication.
Migration to React Native
Plan and execute a migration from native or hybrid stacks to React Native with minimal disruption and clear technical direction.
Desktop App Development
Develop powerful cross-platform desktop applications that work across Linux, Windows and Mac.
Web App Development
Build a solid foundation that meets latest standards and scales easily to other platforms in the future.
