Theo. Welcome to Dev mo dot FM. A podcast dedicated to the tools, techniques and technologies used in modern Web development. I'm Andrew Welch from N. Y. Studio 107 I'm Patrick Harrington from mildly Kiki in Boston. And today we have on Polo Elias. How you doing? Follow pretty good. How you doing? Good man. And we're here. We want to talk to you about building mobile APS with react native. So if you were out and Pamplona, Spain, at the running of the bulls and they have just let the bulls loose and you're running, you're running for your life. You get the red bandanna on all that kind of stuff And someone who's running next to you says, Hey, what is it like building mobile apps with react native like, What would you say to him? I would say, Ah, building actually react Native is a really fun way. Thio build something tangible that you can put on your phone using your experience with Java script. And if you have react experience, that makes you Yeah, because I mean, one of the questions I would ask is also why I react native like, why don't I just learn swift and do it that way. I guess that depends on your experience. If you're a traditional Web developer, you probably don't have a background and swift or objective C or some of those types of languages, and you can just dive right in Thio Building a React native app. If you have that JavaScript sort of background, the way development sort of mine site it, it sort of translates how you build things on the Web into something that you can put on your phone. That's an actual made of at and not just a little P w air or Web app. Are you making fun of my P? W s follow hell now you guys are awesome. And probably PW ways can probably replace a lot of really small, simple native acts, too. So it's Ah, there's a place for everything in the world. Yeah, and I think there are. You're right, though there are cases where you do really need that extra little bit that you can only get from a native app. And yes, you can do quite a bit with offline usage on ah pw and that kind of stuff, But I think we're not 100% there in terms of like, you know, I want to fire up this app. Well, I'm in the middle of the Alps, you know, going hand gliding with with Ben going up there or whatever. But there are certain things that native APS or just kind of nicer for and the reason they're a little bit nicer for it is that they're built for that ecosystem and they can interact with the full, you know, sweet of AP eyes that are available, whether it's on IOS. So our android or that type of thing. One of the big misconceptions that I had about react native when I had just, like, kind of heard of it was I was like, Oh, well, that's really cool. You know, I can build this thing using react in my Web browser, and then I'll automatically get in IOS and Android up for free along with it. That's not how it works, right? No, it's also the sort of the whole idea behind, react and react. Native is its. You learn once and write anywhere. It's so it's It's different from the right ones and running anywhere that, uh, I had that Ms Cassell misconception as well. One of the reasons you can't do that is react. Native has, ah, ships with a bunch of primitives that you use for iPhone or android specific uses. So instead of a div using react or you build your own component div inside of that, that has something called a view. And that axe is like a block level container that you can you can still use flex box to lay out your ab. But they're the primitives that you used to build the app, what, differently, and behave a little differently, too, depending on what we're building. Yes. So let's take a step back here and just give a quick primer on react, and we're gonna teach people how react works. But just some basic stuff. So if you're writing html code and you got this Div and you put in class equals whatever and then style equals whatever the style and the class, those air properties of that particular component, right, the def, right? Correct. Yeah, you could think about was, like, current parameters of a function. Yeah, So when we're doing custom components in react, we're doing the same thing right, So basically, and this is simplifying things to some extent or another. But react components are basically properties and render functions right. In other words, you've got a bunch of properties you can pass down. In the case of a div, we've got a class property and a style property, and there are a bunch of others too, right? Yeah, yeah, we're on click and you can add your own or whatever. And then, in the case of a div, right, the brows already knows how to render it. But in the case of a react component, we can write some code that said, that takes in these properties and knows how to render this thing right. Is that kind of like I know it's simplified, but that a decent summary of how it works? No, that's a That's a great summer, and it's It's I mean, that's the boil. When it boiled it down, it's That's what it is, right? It's a fairly simple concept. Once you sort of get your head past the whole, like, what's this J sex stuff? Why does it look like HTML? Why's it different? It sze pretty much wells down to that you have your components that are in a react app would be sort of accustom Component could be like a header component that you write, but it will have a header tag within it. And then whatever other styling your components are or HTML elements you need in there and then you pass down props that can include ST ST changes handlers for, you know, you wanna control when something is clicked, you confront a function just yeah, that's that's pretty much what it boils down to. Yeah, And I guess I'm just trying to draw an analogy for people that maybe have never used react before. You know, you kind of have conceptually, because have you been writing HTML? You've been writing components like just think of a div as a component, right? And then think of the class and the style things that you pass in those air properties, right? And then, if polo wanted to make you know, polos, kebab component, you would just write that as Pollos dash kebab, and you can pass in whatever properties you want, you know, like maybe meet equals this and vegetables equals that or whatever it is that you want on your kebab component and then you can write whatever s o the and this is in it. In the case of a div, the browser knows how to render this thing. In the case of your custom component, you write a little bit of code that says, okay, given these props and given state and whatever else is, you know, factored into this thing, render the render this component right and render the actual HTML that should be output for this, right? And the reason why I'm giving this quick primer on react is my understanding, and I have not done anything in react Native. I've been kind of buying it from a distance, you know, for for quite some time I read a little bit about it, but I haven't done a ton with it. But my understanding is the way that it works is you can't just take your react code and start using it there and get a you know, app on Iowa's, um, an android for free because what ends up happening is react under the hood, has got a a Dom renderers and that gets swapped out for react on when you're using react native or sorry. React Native Dom when using Iraq May Is that how it works? Yeah, I don't I don't believe it's called reactive. Don, I have to go back to being Documentation has been, ah, while since I've read those docks which, incidentally, tells you how little it matters if you don't even know what it is. Yeah, basically something you set up at the beginning of the right, like in your entry point. And so yeah, it's like goes back to what I was talking about before. The reason why you can't just port things over are the primitives that react uses are a female ailments that you're used to use it in the matter Headers, dibs, spans, paragraph tags react native they don't, they haven't They don't use those that use their own primitives, which translate into like of you would be similar to a div text component. Usedto wrap your text around. There's different sort of lists and flat lists and that sort of thing that you can use to list things out. So you Els ordered. Listen, that sort of thing. I guess what I'm trying to get at is that you would then write this, you would write your react components kind of the same way that you used to, although sub components that you would use in there would be different. But what's happening is instead of it, you're kind of like swapping out of render right. So you can think of it from the point of view of, Well, it used to render html. And now it's gonna render this thing that makes sense in a IOS and Android context, right? Her and a lot of the a lot of what you just need to do is switch out the primitives a lot of the way the Java script runs will still work within react natives. So if you have click handlers or events listening for certain things and you know, when you re render the state of props, the components were rendered that well, they still should all work the same minus any sort of differences and have, like, a view works compared toe paragraph tag or spanners like that are sorry did. So it sze pretty close. We just have to be careful about the primitives you're using to build up the structure of your application. Like the view of I guess the real idea here is that the reason we might consider react native is if we know Java script, right? And we know react. And we want to make a mobile up right, because we can do it other ways. But if we already know Java script and we already know react, this gives us a way to leverage an ecosystem that we know and a methodology of working that we know to build some pretty cool stuff, right? Yeah, it's this very familiar. Once you have some react experience to go into a react native app and spin went up on dhe. Start building it there. There are really there are some differences in how you build and deploy their met Vastly different, right? But that's a holder. Other talk. The other thing. I'm going. So you know, I'm sure, and I haven't built into the whole react native libraries and what they give you. But are you then able to bring in any know Js library that you're familiar with and know how to use being, you know, Axios or Apollo, our view or whatever. Love you for staying, react, but and bring those in and get that running in. Does it play well with all outside libraries? Are there times where it doesn't work? Well, uh, maybe my experience is pretty limited, but I haven't run into any issues of bringing in a sort of standard job script libraries. You can use patch to grab data. You can use any other sort of package it can bring in that you're used to using in react. I'm just trying to think off the top of my head. I haven't really run in any running into anything out of the ordinary, but that could be because maybe the absent building aren't secret complicated. So I have I have to think on that and get back to you. Well, it may. My guess would be that if whatever this thing you're trying to use assumed that there was a dom Renderers under the hood that it might not work. Yeah. Yeah, that's true. But I haven't brought in. I haven't Yeah, I haven't used things that would like I haven't used, like, a J query slider in a reactor native I built my own. Or use that one that's built with react components so that definitely I don't think that probably wouldn't work, right? And well, in a lot of the things you might use a Java script package for are gonna be built into react native anyway, right, cause they're gonna layer on top of, you know, existing android and IOS like the you ike it, for instance. Right, Because it's it's really rich. You ike it that you get when you do a nihilist development, right? Yeah, but the way react native works is it actually has a job, a script thread sitting between, I think sitting It's somewhere above the, uh the actual native portions of the app. So you're still running sort of native judge of a scrap JavaScript, and it gets, you know, pulled into the actual the native components and rendering of the native components on the screen. With that John script threats, sometimes you just have to be careful about blocking that thread with complicated animations. Sure, there has actually been a lot of good work to combat that and to fix that issue so you can get a truly native feel sometimes in the past reacting out of absolute feel, maybe a slight Janko or slower scrolling or just a little bit off from a native, swift, built or objective c at because of some that performance. But a lot of the library's been doing a lot of great work to get around that sort of thing. Yeah, I mean my understanding from looking into this and I'm coming from a I used to do IOS development, but a lot of my experience is kind of dated at this point, but I have been looking into it, and I think it may kind of be like anything else, like you could write it poorly and it won't work well. But it's not like the actual platform is preventing you from reading it well and having a solid performing at because some pretty high profile Apsara written in react native right there. R and there's also quite a few. I mean, it's probably more absolutely realized, are built in, uh, give us a couple. Just give us a home. Airbnb used to be one, but there's a couple start ups I've been talking to you right now who have their entire APs built on react native right there. Well, that's what's really surprised me was I knew it was widely used But there's quite a few folks that I've been talking to recently that are looking for react in need of help and have like these, you know? I don't know, thinking what I could say, what I can't say, But, um, I planted, man, What can I say? Um, but like, you know, in the health space, actually two in the health space where you have to worry about HIPPA compliance a whole bunch of other stuff that they were confident and using react native is a platform for the application that they shipped to the end users. Yeah, it's been It's been pretty eye opening to Well, okay, so let's start with an easy one. Facebook, right? Yeah. Isn't that Brennan react Native. I know. They're messengers written. Reacted. I can't remember if they kept the actual Facebook app in reacting. I can't imagine it is that there was such a big l cry from their old app, which was done, I think, on HTML five Technologies. And they ended up having to go back and rewrite it in guessing objective. See, at the time, it could be some swift by now. Yeah, I haven't heard anything about it. switching back over to a ah compiled from Yeah, well, a couple of examples of the other raps. So Instagram is one that least was I think it still is. We've also got discord, right? Something that in the craft CMS community people are using a good bid on their mobile device. Well, there you go. That's written in react native and their their whole whole bunch of as you mentioned, Airbnb Bloomberg, Facebook ads manager. I mean, it's my real point. Is that okay, So I'm gonna take a step back. It's story time. Everyone pull up a chair left for That's what I live for. So my my wife works works for a company that I won't name, but they're decent size company and they're not in the tech business, right? But they are building their own IOS android apse, right? And they also have a website. So they have an IOS and android team that air building separate code basis. They also want to then take what they have built for ah, IOS and Android and they want to then have that appear on a website as well. And then they also want it to work in a kiosk situation, right? So they got, like, a walk up kiosk or whatever. So they're looking at having four almost entirely separate code basis that they're gonna have to maintain which anyone that has ever maintained a code base. That's that's a nightmare, right? In terms of trying to keep things in sync in terms of allowing marketing, too. Then, you know, have the ability to move quickly and change things and do promotions. And that kind of thing. It's just kind of a nightmare. And one of things that I mentioned casually to some people that work there is you know, Hey, you know what about doing something like react native where you could have one code base. You would still benefit from having developers that no IOS and android Well, because and we'll get into this little bit later. But there's always gonna be that last percent where you may need to do a little bit of native coding. I would imagine for some abs anyway, and having experience in those areas is gonna be helpful, you know, just understanding the glue and how things were kind of stuck together and everything. And I said, Well, you know what about doing something like this? And the answer I got back from everyone was that we were burned in the past when we tried to do one code base, so I would imagine they did something like Cordova. You know, we're on. And they ended up with a crappy Web, you kind of thing. And just things didn't work out well, Or it could be like what we talked about Where Doesn't matter who you are, what technology you pick. Like you could do a crappy job building it right. But now they're forever scared of doing a single code base for anything. And I I listen to this, and it just drives me crazy cause I'm just like you can't be. You can't go the rest of your life eating raw food just because you were burned by fire once you know what I mean? Like, you still have to understand that there are ways that you can apply apply fire, that it's actually going to do things really, really well, and it's going to do the thing that you want, you know, and especially for an app that I think that is more gooey than anything else. I think a single code base makes total sense, you know, because you can craft that up. And if the back end is separated into, like, a platform, which is an A p I that it ends up calling a unified code base with something like react, native or native, script or whatever. It's just a wonderful way to do it, you know? And it just drives me crazy hearing about them going to maintain these four could bases, cause I know what's gonna happen. You know, they're gonna be out of sync. There's gonna be constant problems with one platform or the other. They're not gonna be able to move quickly. And I think their attitude is Well, we've already invested so much in this, but that's kind of the fallacy of ah sunk cost right, cause the real cost is gonna be What's it going to be to maintain this thing for the next five years? You know? What's it going to be to have this same be able to move quickly enough to kind of match our speed in terms of what marketing wants to add to it and that kind of thing. And there again they're talking about adding another platform, adding a kiosk to it at adding a Web component to it. And I just like I already thought it was crazy that they had to code bases to begin with for this relatively simple app. But then planning to ADM. Or, like Max, make it, makes what little hair I have left stand on its and Paulo. What do you think? You know, it's It's definitely I wouldn't even want to be in that position. I got to manage all those different colored bases, and it's also not a matter of having different code bases. But the interesting thing about react and react native if you happen to build your APs sort of in the those ecosystems is that it's not that much different to maintain and work in either one. So in a situation in the past like that, it's like where they had multiple code bases for different APS. That kind of did the same thing. One was like a PHP app. Another was a job hap and so, like people maintaining it either had to have multiple resource is run, even contact switching, switching. If you're that one person that has to try to go back and forth between them so that the cost of that, I think, grows exponentially compared to using tools that are sort of siblings of each other. Yeah, and I'm not sitting here that, you know, I'm just chowing down on the react and react native dog food, you know, because I I like doing things the native way in some cases. But you have to look at what the APP is and like, what does it really need to be a native app for certain? For a lot of things like No, clearly, no, because there there are multi $1,000,000 company says you mentioned that have built their They have built everything around, react native in a unified code base, and then they don't have an android team and an IOS team and a Web team, all of which need to be, you know, have their own project managers and then have you no one over our King project and trying to keep everything in sank like it mean. That's it's like herding cats, you know? And even for a tech company, maintaining these different code bases is adds a lot of overhead And if you're not a tech company, if this is not like the primary thing that you do, I just can't even imagine. You know? I mean, it's just, it seems horrendous, but this gets back to something else. That was a misconception for me about react. Native before I looked into, it was like Okay, well, cool. So I can write this thing and react native and I'll get my Iowa sap. I'll get my android app and then also have something I can put up on the Web. But that's not the whole story, right? Right, It's Yeah, it's It's a look that there are differences in how you get things, get picketing, working for different platforms. So I guess what I mean is, I can't just take the react native coat and then put it in a Web riser. I have to use something called React Native Web. All right, Yeah, you can do that on your own React components, but yeah, you can't use those react native components for the React Native hap right inside of Wet, a Web based application because of the way the primitives are constructed right primitives. I'm meaner the way it's like the browser elements when we spoke about before, Dib spans paragraphs headed for sort of tag that the president has had to deal with. React Native has different primitives that inform that sort of the native compote that we have, the way the native components are rendered. So texts, yes, views, even though there's different types of buttons like Touch, capacity and I love bunch of difference or little nuances and how those air put together that you can't just, like, poured over, you have to sort of. That's why you hearken back to the way react, native and react, sort of whose slogans are learned ones, right? Well, and that's the thing is what we're doing. We mentioned earlier that we're swapping out the renderers that used to render HTML for something that renders these components that make sense in a native context. So since we've swap that out, we can't just stuff that on a Web browser so we can use something like react Native Web, which then implements all of these components that react Native provides to you these primitives or as you mentioned, and this is something I hadn't even considered doing because it sounds like a lot of work. You could write your own version of each component, right? So if you want to put it on the Web, you can write your own text component. Correct. That sounds like a lot of work, though. Yeah, it is. But it's still in the same context to so right. No, it's going. How does that compare? I've heard a number of firms that I'm familiar with looking toe Ionic, I think because it it does try to do a little bit more in terms of working with, you know, with P W. Is working with ah reacted. They're actually supposed to be working soon with a view and other, like the angular. Do you know anything about how they work? And you know, not only that, but they don't tell you in just to react possibly is your choice on what to build with. But, um, that they would let you just natively, I guess. Go to both A mobile app to a progressive Web app. Yeah, I believe those tools are still using, like, sort of native web use. So they're home. They're not building out sort of the native components to make it an actual native app, so it's got a sort of think of it as a shell. The native app is a shell to Web pages. God, it was more of a rapper, you know, He Ah, the native wrapper around. Ah, Web view. So any I'm wondering, then you end up with kind of that. I think we all remember when the iPhone first came on. There were a lot of cheapo APS coming out that didn't quite feel right, and nine times out of 10 they were a weird HTML thing. Yeah. Yeah, that's where you get some of that Jenkins scrolling issues. Okay, Uh, the lag. Like when you press a button, it just feels a little off. Yeah. 300 millisecond delay. Yeah. Yeah. I think some of those sort of projects have tried to improve some of that, and I think maybe are trying to go the route of rendering native elements, but I don't know. I haven't used them in it recently. Are recently enough to actually say for sure that's the case. But that's why you feel the Jenkins. They used to just be shells toe with these. Sure. And I don't know either and we We had them on a couple of guys from Ionic on recently to talk about stencil, and I was a really good conversation, but we didn't delve into exactly how the Ionic framework worked at all aside, I really don't know. I mean, it does. They do have a guide up there that says the definitive guide to hybrid versus native app development. So hybrids, you know. I mean, you're right, there must be some mix, but I don't know what that is, but whatever we'll have them on, and we'll talk about that with them at some point, too. But I guess that's the interesting thing to me. Is that you know, for instance, this particular project, um, that I was mentioning that my wife's company is working on. If they did take the time to start, you know, they already or down this road where they're developing the IOS app, the android half and the native Web app. If they started now consolidating the code with eventually the result being merging everything into one code base. I mean, it just seems like the long term gain would probably be there, you know, because they would then get the IOS and Android app, you know, quote unquote for free. And they would have one code base where they would be designing things once, and they would have one set of key ways that had to have to deal with it because I realize there would be two different platforms. And, yes, the key ways would be testing on both IOS and Android. However, because the projects would be in sync, that could be in one step of the process. You know what I mean? And then if they needed this thing to be on the Web, then that could go This weird round trip where you go from React, which works in the Web browser to react native, which doesn't to adding in react, native web. So you go full round trip and then their app would work also on the Web browser, and it just seems like I don't know. I mean, maybe it's one of those things that it just seems so beautiful and pristine from an external point of view, or from a theoretical point of view. But you've actually done it. I mean, it does this actually work pretty decently, going back and forth between the Web. Use the native runner using react native in general to build IOS and Android APS and then also react. Native Web. If you've ever done anything with that, too, then you know, make it so you've got a code base that is available in a Web browser to Yeah, I actually haven't had to do work on a project where we needed Wet and Native Mobile, but, uh, from what I when I was looking at react Native Web just to get a better understanding of that looks like a really great wrapped to go because it helps sort of ease that pain kind of translating those components over. That's and that's really the only way. I'm not the only. But the biggest pain is just getting those components ready for Web and ready for the native browser writer native. But you, Paulo, is someone that you know, comes from a expression engine craft CMS kind of background to then you've been working at IDEO for a while, where you've been doing a whole lot of stuff with reacts and building Web APS to then start building actual native IOS and android. EPPS. Was this a pretty seamless experience for you. It actually was because I had the JavaScript and react sort of background. If you have, you could actually dive into react native, which a little job JavaScript experience. Their documentation is pretty good. It's getting better on and then you can learn react after that. But it's It's fairly seamless, if you can. If you're coming from some sort of Java script background, you don't have to be a super expert. Of course it helps, and it definitely helps make things go faster and much easier to understand how to put things together. But it's just getting your head around a different way of building. So you there's different sort of performance implications you have to think about when you're building a website versus and mobile app. You still want to try to keep your assets is optimize possible. But there's different sort of scenarios that you don't have with a Web application like, how do you deal with offline stuff? Have the explicitly deal with that if you have portions of your app where you're reading or saving data, or even just like in our case, in one of the upside of building an idea or the building ideo it. We decided to use contemplative CMS and just suck down all the assets and save the content. One big Jason Blob said. All that was on the device and we didn't have to worry about about, you know, reading data while someone's in the field trying to use the app so everything's available right away. Yeah, or you could use a local cash and then attempt to attempt to grab updated information. You know, if there's a network connection, and if there isn't you just use whatever is there, right, right, right. And that's just something you have to keep a little bit more forward in your head. Then you would've normal sort of Web app that you're used to used to building is not a lot of people in the street. It's a specific P W A. Not a lot of people think about Well, what if someone's on a train and I can't, you know, say this to do list item, You know, it's it's not something that is at least not yet. It's not something that people are sort of keeping on top there, mind. Yeah, and you know, there are a P eyes that Google has for work box that help make you know that kind of information sink a little bit easier. But I agree with you like it's a mentality shift. But I want I want to ask about your mentality and I don't mean your mental. Don't worry. We're not getting into the deep, dark corners of your mind. Don't worry. I'm gonna have enough time for that. No, but the question I want to ask you is like, Well, when you're working on these websites and react or whatever and someone approached you about, you know, building a reactor native version of this thing, How come you didn't just say, Oh, I'm not an Iowa's developer or Oh, I'm not an android developer. Well, because I'm one of those idiots that he likes to take on the challenge of like, Well, I know this exists, and I know this technology, so no, why can't I built this thing? Um, yeah, so I mean, is it especially if it's something that sounds like I would enjoy doing, I feel like I can do this. I mean, that's I guess that's how you That's the way I've sort of built my career is you know, I don't You don't know everything. And you know what? You don't know. You just have to learn how to know it. So I think the only way to know it is to actually use it. And I think that in almost every case when I've looked at something from the outside and thought that it was really, really complicated or really hard or whatever After I got into it and started learning about it, it almost never was a CE. Hard as I thought it was gonna be, you know? And I think there's just some amount of fear you know of Oh, this is gonna be too hard. I don't even want to try and figure this thing out. But that's something that drives me crazy Is I hear this all the time. People say, Oh, I'm not a PHP developer or oh, I'm a Web developer. I don't do android APS or, you know you know what I mean. In other words, people compartmentalizing themselves, and it's definitely true that you will gain experience or expertise in a niche where you do stuff. But I think people are undervaluing how universal some of the skills are that they know from programming and that picking up a new language or a new platform is almost never as hard as a lot of people make it have to be. I totally agree with all that. Yeah, it's I mean, I was sort of I was in that same boat for a long time earlier in my career because, saying some things they seem so daunting from the outside, right? And then, like you said, once you start even just reading the like, Quick start page or hello world after like Oh, OK, you know, you do have to get some experience to understand something, the nuances of it. But you can't do that until you actually dive in and understand the basics and the basics for a lot of this stuff, especially for the Web work we d'oh, it transfers and translates over to a lot of other sort of languages and types of products or projects, especially sort of native at developments that sure especially I think Swift is. If you understand Java script, Swift is pretty oppose, approachable as well. Yeah, and I'm not trying to say that there isn't complexity in these things, right? Cause I know there is right. And I know that a lot of these things air, you know, they're kind of infinitely deep in terms of, you know, how far how far do you want to dig down below the surface, right? And you could spend forever. They're All I'm saying is that I don't think that getting up to speed or getting started on something one of these things is necessarily is as hard as a lot of people will then make it out to be, you know, and think about you know, let's see you work at a small agency and you got a big client that has come in and they say What we want to do this ah website and along with it we want in Iowa's and an android app. And whether you get this bit or not is gonna decide based on whether you can do this or not. Hey, you know, maybe at some point it makes sense to try and try and add some of this to your repertoire, especially if you are already skilled in doing react stuff on the front. It because if you are. And again, this is from someone who has not actually done it right. This is just for me reading and what I've learned about it. But it really doesn't seem like it's gonna be that bad to go from a moderately decent react developer to doing something in react Native. No, it's not. It's not that much of a difference. Once you get the concepts down and understand the primitives, it's it's fairly straightforward. Follow it just It just occurred to me like an analog to this is doing Google AMP. Stuff. I know Patrick hates it because he thinks is like this evil, whatever. But forget about right now. Wait talking about Google AMP Okay, this one here, I didn't mean to prod you didn't mean to wake up, but, you know, learning to build stuff in Google AMP like it really is kind of similar to doing react native stuff because it's killing the Web. No, because you're taking away a lot of stuff that you could have done before. Like react. Native is a subset like you can't do as much stuff, right, cause it's reading to a specific set of components, and then you have these different tags, right? So just like for amp, you'll have a different image tag. If you want to display an image, it's the same thing with react. Native, right? Yeah, yeah, yeah, something. Stop it, Patrick. Stop it. Well, I understand you don't like Google Lamp. Okay, Let it go. Let it go. But the real point is like it's kind of it's almost a subset, right? So isn't it like you're? Are you more limited in what you can do when you're doing stuff in react? Native as opposed to just react? I haven't running in any limitations. There's a tangent that we can talk about how you build with react native. There's a way you can look in the documentation. There's two ways to sort of started react Native project with the ones with Expo and ones with the React Native command line tool. If you go the Expo route. A lot of the underlying AP eyes are easier to use, but there's times where you might need to hook into native codes, so then you got to eject out of it. But in terms of limitations of building an app versus the Web app in react native. I haven't seen any, like, sort of crazy limitations other than you want to make sure you don't have a little just like any Web page. But website is. You don't want to have this 700 made bundle of your shipping a a simple sort of credit. Well, I guess by limitations I mean something like, you know, the number of quote unquote components that you get for free when you're building a Web page like there's a lot of right there's a div, there's a P There's a span. There's a listers of that, But in react native, if you're displaying text, there might be just like a text. There is that that is different. You have your head around. How do I reuse these or make him reusable to have, like, How does this minute a paragraph, right? Minnick, this specific styling of like a a span for certain areas of the app. So that is, it's it's a matter of just getting used to it and in finding ways around that, or seeing how other people are doing it, adopt how they how they do it. So that's there's there's nuances that you have to understand. I guess that's the best way for me to predict. So my understanding is that part of the equation is writing the code, right? And the other part of the equation is all of the provisioning and all of the nonsense that you have to go through in terms of getting an actual AP published from my experience. And again, this is somewhat dated. But apples process for doing this is incredibly, incredibly annoying and involved. And you have to have signing chains and all sorts of I mean, it's just it's crazy Android, from what I recall was relatively simple in terms of getting this stuff up and working. Is that something that this Expo thing that you're talking about is kind of helping with? Is that side of the equation? Yes. So if you stay within the Xbox ecosystem, which probably other tangent for about 80% of the APS out there is that whole 80 20 rule you could probably get away with using the ecosystem. They do make getting things in the APP store a lot easier than if you did it natively with your active command line and have to do it all yourself. you're gonna be just, like, building and signing at a nap. Built in, injected, see or swift. It's a hoot. Jump. Well, let's define it. What is Expo? Because we've been talking about react native and and then we can do you use it for building these wonderful lapse. What is Expo and where does this fit into the equation here. So the way I explain Expo is it's kind of like a, um a framework for building a framework for a framework. I know it's a framework that sits above react. Native. What's interesting? What they're doing is they're actually starting. I think they just announced this. They want to start targeting more than just native applications on the phones. They wantto start building native desktop APS APS for set top boxes. Apple TV I A T v O S T V Oh, yes. Oh, that's kind of cool, but it's basically say think it was a wrapper around react native, where they tried to simplify, for example, using a map safe guy, you can use their sort of maps way of doing things. It's probably a little bit simpler than that. If you had to do everything by hand be a reactive, commits Eli. And with that, with that rapper comes a whole ecosystem on expose expose that I know that you can opt into that will allow you to basically use their tooling for their whole your holes from life cycle of your app. So using Expo to build a raft, they have, ah, Expo client that you saw on your phone that allows you to play and feel and touch that phone. Felt that app on your phone without having to like so, like test flight rigmarole of test flight. Yeah, you have to do that. That is much, much simpler for the testing sort of phase of things. I mean, from what I recall, Paulo from doing app development. And again, I haven't written anything in react native. But my guess would be that if you if you have some experience in javascript and react, what's gonna take you more time than anything else is figuring out how to do all the nonsense round because, like if you want to listen, you're building this app and you want to test it on an actual device. Will you have to go through test flight and you have to have provisioning profiles and you have to provisioned the phone. And it's just a big like It's a ball of stuff that if you used to doing if you used to just writing stuff and re reload the page. And there it is like that's not how this works, right? No, it doesn't. And it gets frustrating. Yeah, that's actually part of the process that not looking forward to when the sap is done. But it's Yeah, it's, uh, I think I think we've used the explore out just to make it is at the end of the day a fairly simple app that we don't need to tap into any native modules that require us to eject or anything. So we could probably use the explosives ecosystem Thio building, deploy and get into the APP store. So and also in in a setting, like where you're building it for another company or your within a larger company. Having in one account sort of manages this sort of workflow and these processes is, I think, fairly, uh, fairly advantageous to your sanity. Well, you've used the term eject a couple of times, and I know that this is something that people who are in the ah lot of these framework worlds will be familiar with. Because, you know, if you're using something like create react app or whatever Oh, are any any number of other of these kind of starter kit kind of things? Eject is a term that they'll be familiar with, but maybe not everyone is. So what does it mean to eject from something? Yes. So in the in the world of react native, if you start out with the Expo way of doing things that you're using Expo to build your app and you realize Oh, wait a minute. I need to use this native, not native module. I need to plug into or running to something that expert isn't support. You can run this command that will basically take you out of that expo ecosystem. They still sort of bundle things up so you could use any of the components or a P I. C. U views with Expo into its own react native cli ready application structure. So it's it's basically taking what you started an expo. Getting it back to sort of the bare metal of what react native cli would d'oh! And then you're left with the whole preflight and certificate signing and all this other stuff when you go toe to toe, build and deploy up. But it gives you, you know, the more more access to integrating with other sort of the native modules that you would use eso. Things are what enabled mate of module is is something wrong with the way I define it? It's something that builds an objective, objective C or swift that you need to bring into your react Native happened sort of bridge those together. You can't do that with us. Vanilla Expo project Got it. So basically, when you're using their framework and everything is great, you may never have to leave and you're good to go. But if you do, you need to do so. If you do need to do something outside of what Expo does, you're not completely screwed. You can do what's called ejecting, which basically it dumps all the config stuff out, and then you're just on your own and you're out of their ecosystem. But you can do whatever you want, right? Exactly what you think, Patrick, you up for ah, for reading your own maid of APS here. I honestly I mean, this is the only way I would really consider doing it. I just don't have the time. I'd love to learn Swift. I've seen enough to think it looks nice and all. I don't have time or wanna learn Objective C or forget about Android. No, I I've said time and again, like if and when there's no that itch to scratch of. We have a client. It's looking for something or just a good opportunity. 100% is the way I'm going. I don't know if it'll be react native or Ionic. I'll probably look at both, but yeah, it just makes a lot of sense if you feel comfortable Web technologies. This lets you make that transition a whole lot more easily. So if a client came to you tomorrow and they said, Hey, you know, we want to build this software as a service thing and it's kind of an APP ish thing on the Web, you might already be thinking, Well, it's probably gonna make sense to use some kind of a framework for it, right? And then if they say well, we we want an IOS and android version of this is Well, you know, I mean, I think that's the time where you start looking at this and say, Okay, well, what are our options for doing this right now? They're even. I mean, I would even start to just put the bugging clients heads. If you know there's someone out there that might look to do it and they may not have a ton of budget for it, but it's a small enough project that you get our, you know, get into it and kind of figure it out on your own so else's time. But, uh, no. But on this tomorrow one where there's not a lot of risks because any time you know there's gonna be a learning curve with some like this, even if you know, react or if it's a view based one, whatever it is is gonna be a learning curve. I was like, the idea of, you know, something simple, maybe at some of the using Flicka basic kiosk or something? Um, yeah, that could be really cool. And that's the other thing is there is a decent market for creating bespoke things for kiosks or for exposed or not, Not the kind of expo used to make APs what actual expose that humans go to. You know, our interactive type of things and those air Probably pretty good cases for doing it in a platform like this, right? I mean, one of the things that I have been thinking about ISS Well, let's say that initially your target market is just and IOS app. You can build it in swift, or you can build it in whatever you confined engineers that they know all that stuff. But if you build it in something like react, native or native script or any of these kind of interim formats, when the client comes to you in six months and sell the you know that the IOS app went really well, let's make an android app. If you've done it and react native, you can just like you, kind of just build it right, Paul, you like? All right, here's your android app. Here we go. Yeah, pretty much. I mean, it's not that simple, right? But it's closer than it. It would be when you're starting from scratch exactly as much. It's much simpler. There are places where you have to sort of specify if you're targeting IOS, you're targeting Android. You have to code something a little bit differently. So it's it's. But it's that still much easier than having to maintain a hole of a code based on a whole other language, right? Um, and it's really not that it's not that I don't think sometimes difficult, because that's probably the best way to put it. But it's it's less cognitive overhead, and it's much easier laid out to do it that way. And and that's something that I think a lot of people don't think about Enough is. A lot of times it's focused on What is it gonna take to build this thing and for a decent sized company that is going to be married to this thing for a while? What you really should be thinking about is in addition to what? What does it take to build this? But you should be thinking about what does it take to maintain this? What does it take to keep this thing updated? What does it take to, you know, keep this code based something modern that we can actually be using? And that's something that a lot of people don't consider unless, you know, unless they have experience in the tech business and they know how money mental this can be. But a lot of times the cost to actually write the thing can be less than the cost to maintain it over, you know, x number of years. You know, exactly. And that's a case where, looking into something like, you know, again, whether it's react native or its Ionic or any number of things, it makes complete sense. Toe be looking into this stuff because and I've seen it a lot not just for and consumer APS, but also for bespoke caps that are made for companies they don't wanna have to maintain a whole Iot esteem Android team Web team You know, just for this app that is going to be used inside the company. Build it in something where you got one code base like Give yourself a break. You know exactly how Patrick, I think you should build the next iteration of mildly geeky. You should build it in react, native and then used to do the round trip from react. Native to react. Native Web. I'll get right on that, uh, you know, I do want to honestly do that site over with some sort of front and framework. Uh, that, Yeah. I'm still tempted by doing a like Gatsby or grade Summer sun like that. I don't think there's the the the audience there for, Ah, full native experience, though. You don't want people to visit your site. Milder, geeky. And they it says, Hey, do you want Oh, yeah, Door, actually. And pal, I don't know. I don't want to wrap up, do you? Are you an android person? Do you have Android devices for testing? What's that experience? But actually, when it comes to differences is it is a pretty easy You're the edge cases. I have X. I have devices to test on in the apse I've built again. I don't know if they're just cause they're not that super complicated, but V I haven't run into many edge cases and the way to handle different sort of styling in dealing with way. So the Andrew it was material design. So what? Whatever they use in her, compared with the IOS signed guidelines implemented in the native APS on there, you know there's places where you have to adjust in tweet things and spacing or do something different. But in all those cases, it's been a relatively simple fix, and most of them it's just sort of Ah, simple turn eri in this styling definition. So it's it's fairly easy to one. It's actually once you hit that, that's sort of what you think. It's a bug. It's easy to figure out what's going on, and then the documentation is pretty about helping you fix that and understand that because my understanding is it will. Actually that little layer that we swapped out on IOS. It's gonna be using native Iowa's components on Android. It's gonna be using native android components that conform to material design or whatever, but yeah, I mean, I could definitely see where there might be a case where it's just like it's not. It's not exactly right. You know, like the android waited present things, needs a little bit of more space around it or isn't the same kind of component as three. Iowa's version right is, and I think Android has a sort of native sort of home and back and forward type buttons at the bottom and some friends have to deal with that sort of stuff. If you're targeting both, I didn't mean to cut you, and now it's fine. But again, then we're dealing with finishing like the last 2% versus doing everything bespoke, you know, for each platform. And that's especially for a lot of the APS out there that are mostly gooey. That just seems like a monstrous gain. Exactly. Yeah, it's again. It's the whole name maintaining multiple cable code basis versus doing it all in and one, Yeah, and And I'm And I'm not gonna downplay, you know, having a unified code base because I think that's wonderful. But there's so many other parts of the whole development que a process that you then are streamlining, you know, because then you don't have separate project managers for each platform. You don't need him. You don't have separate Q A's for each platform. You might still have you no additional key ways, but they're all again. They're all sinks on the same cycle, and they're just many parts of not just the code base itself, but everything that orbits around building an app that then just becomes a lot simpler to deal with and I don't again. Just like I think that the cost of building something versus the cost of maintaining it is something a lot of people don't think about. I also think that the cost or the benefit of a single code base versus the benefit of everything that orbits around that, you know, I think that that is a really important thing as well. Have you noticed that at all, in terms of our every ever even been in a situation where you're going from multiple teams that get pared down, I actually haven't been in that situation because the teams I've been on have been relatively small, right? But I can imagine that that's Ah, another situation where it it helps. Sure. I don't know, man. I'm looking. I'm looking at mildly geeky dot com, and I'm seeing some stuff that's up here, and I'm like this. This could be an app, Patrick. And that about does it for another. Well, now, now perhaps, are becoming those, like, seedy business cards of like what? Yeah, uh, but, you know, I mean, I think it would be kind of a fun project, though, right? Like if you're already considering rebuilding this thing in in some kind of a front and thing work or something. I mean, you know, you could target react native web and just build everything. I know it sounds weird, but you could I know you could build your It just feels like the whole thing would feel like a nap at that point around. And I Yeah, I think you know, you made a very good point where you want it to still feel true to the OS. And I'm sure you then have to get to maybe some conditional saying, Oh, if our bill target is this, like, let's put in the back. But now if our bill target is that, you know, let's make it feel at home in IOS right at home on Android because, yeah, one size fits all approach, you know as much. So like, PHP storm, I'm like us. It's a native Web app. A native Mac apple probably feels so much better. Or if this, you know, I think it's a really good idea, though for a lot of cases, just where people are building APs. Unless you're doing something that absolutely needs toe, have you know perfect usage of the GPU and perfect posture, animations and all that stuff. But a lot of stuff. If it's you, I and basic functionality and Chapin around, I feel like this could benefit a lot from it. In terms of animations and performance and stuff. There's actually this guy on YouTube. I consume it. I can send you guys a link that sort of tries to mimic native animations and doesn't react Native. And it's actually pretty impressive how, how well they translate these. I'll see you guys in the link. Yeah, please, too. And Patrick, you touched on something when you were discussing things that I have been through in talking this thing through with other people that were considering maybe using something like react native. And that is, well, we don't want this to feel like some weird monster that doesn't feel like a native android app or whatever, right? The reality is, I think, for a lot of the bespoke style APs, that company's heir building, a lot of people are building these APs that are essentially glorified stores, you know, like and in those cases, there rarely is a ton of native you. Why, that's in it anyway. It's usually that whatever the native branding is, you know, let's say the store is Ah, let's say it's an apple store. So we've got an apple app for buying stuff. Well, you don't really need to worry too much about the look and feel of on this app on Android and on IOS. You really care about the apple looking feel, right? That's gonna be kind of across this entire app, you know what I mean? I don't know. I mean, there definitely are certain parts of the app that should function and look and work like a native app. But for what a lot of people are building, I don't I think that's not that huge of a concern, you know, But that about wraps it up for another episode of the dead mo dot FM podcast. If you'd like to have every episode delivered to your favorite player, you can subscribe the R s s or find us on iTunes or Google play. And if you like what we're doing, please review the show on iTunes. That's where you can leave like a well star rating and a text review. You know, tell us how awesome are how terrible we are. It's the best way to help others find the show. And you can also follow us on Twitter at Dev Mode FM. When we love to hear your thoughts on this episode, leave us a comment on the demo dot FM website where we can continue the conversation for the demo dot FM podcast. I'm Andrew Welch. I'm Patrick Harrington and thank you to our special guest Polo Elias. Thank you for having me. I always do that. I always talk. It's OK. You're eager. It's all good. All right. Well, say, Paulo, that you were incredibly calm, cool and collected describing react native for someone that is a massive £500 bull chasing him. Thank you. Appreciate it. That's pretty good. Help. It was informative and help people. We will find out