In this episode, Mark Rickert joins the show again to talk with Jamon and Mazen about the differences between React.js and React Native.
In this episode, Mark Rickert joins the show again to talk with Jamon and Mazen about the differences between React.js and React Native.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio Podcast, brought to you by Omicron, which I learned is not a Transformer. Episode 223, differences between React.js and React Native with Mark Rickert.
Mark Rickert:
So, I've been making a Christmas present for my girlfriend and I ran into you something really crazy. Do you guys want to hear about it?
Jamon Holmgren:
Yeah, totally.
Mark Rickert:
So I'm making something with an Arduino based board and some LED lights and stuff like that. And, it's very hard to make a Christmas present for someone who's living in the same house as you and watches you walk past them with all the components down to the soldering iron in the garage. But I was trying to do some software updates to this Arduino code, and I got this new M1 Mac and I'm absolutely loving it, but I couldn't get this Arduino board to show up as the serial port on my new computer.
Mark Rickert:
And I was racking my brain for 30 minutes, trying to figure out what was the problem. And, you know what it was?
Jamon Holmgren:
I'm on the edge of my seat.
Mark Rickert:
My USB cable that I was using was from a cheap security camera or device that I had bought. And it only had power delivery, it didn't have data delivery on it at all. So as soon as I switched my USB cable to a different one, it showed up just fine and I was able to reprogram the board, no problem.
Jamon Holmgren:
Oh, that's just classic, isn't it? USB.
Mark Rickert:
It's such a frustrating experience.
Jamon Holmgren:
Was it USBC or was it a different type of USB?
Mark Rickert:
No, it was just a regular USB, it's a USB Mini cable.
Jamon Holmgren:
Oh, wow. Wow. I've run into that myself. So, I have this beautiful 5K display that I bought off of Apple's website for way too much money. And, I wanted to use it with my gaming laptop and my gaming laptop has USB-C out port. And so, I connected it up, nothing.
Mark Rickert:
I could actually get audio to play, but I couldn't get any video. And I was thinking, "Oh, okay, well that's probably because it doesn't have Thunderbolt 3. So, I bought a cable that was display port to USB-C. I thought maybe it would translate. Well, apparently that's the other way. You can go from a Mac to a DisplayPort monitor, then it would work.
Jamon Holmgren:
Oh my gosh.
Mark Rickert:
It's like, ah, come on. None of this stuff works.
Jamon Holmgren:
Yeah.
Mazen Chami:
I just hate how USBs take three tries to be plugged in. First time, second time, third time. Yep.
Jamon Holmgren:
Exactly.
Mark Rickert:
Oh, yeah.
Jamon Holmgren:
Yeah. Every time, you got to flip it over.
Mark Rickert:
I think we can all agree that the USB ecosystem is pretty broken for consumers, but we're not here to talk about USB, we're here to talk about React and React Native today. Huh?
Jamon Holmgren:
We are. So thanks, that was a great segue, Mark, maybe you should be leading this thing, but I am for the moment, at least, your host. I'm Jamon Holmgren, also CTO of Infinite Red. I am joined today by my mind boggling co-host, Mazen, as well as the mind boggling and mind altering guest host, Mark Ricket, who brought us this great story in the morning here. Mazen, how are you doing this morning?
Mazen Chami:
Doing well, doing well.
Jamon Holmgren:
And, how about you, Mark, now that you have your cable mess figured out?
Mark Rickert:
I am doing mind mindbogglingly well.
Jamon Holmgren:
Awesome. Mazen lives in Durham, North Carolina. He is a former pro soccer player and coach and is a senior React Native engineer here at Infinite Red. Mark has been on the program before, several episodes. Most recently on React Native Radio, 217 and 218, which was performance enhancing drugs for your React Native app. He always likes to point out he doesn't do performance enhancing drugs, he does performance-
Mark Rickert:
Decreasing.
Jamon Holmgren:
... decreasing drugs.
Mazen Chami:
Doesn't have anything to do with the mind altering part, so.
Jamon Holmgren:
No, no exactly. And Mark is back for more now, he's a principal software engineer here at Infinite Red, lives in Asheville, North Carolina. North Carolina is heavily represented here today, I feel like I need to move East to join you guys.
Mark Rickert:
Well, I'm moving West, I'm going back to Utah soon.
Mazen Chami:
I'll be the only one.
Jamon Holmgren:
Well, you'll be halfway between us, so that will work pretty well. This episode is sponsored by Infinite Red. We are a premier React Native design and development agency, located fully remote in the U.S. and Canada. If you are looking for React Native expertise on your next React Native project, hit us up. You can learn us more. You can learn us more, that's a great way to say that. You can learn more on our website, infinite.red/react native. Don't forget to mention that you heard about us through the obviously impeccably produced React Native Radio Podcast. And I don't do these things live, these are all prerecorded and everything. By the way, we are hiring. And if you are a senior level React Native engineer located in the U.S. or Canada, go to careers.infant.red.
Jamon Holmgren:
All right. As Mark mentioned, our topic for today is what's the difference between ReactJS and React Native. And for those of you who are React Native experts, and we have a lot of React Native experts who listen to this program, you might be thinking, "Well, I already know the difference." And you might be right, you might know most of this, but you might learn some things still. You might learn some, some stuff, like we have quite a bit to go over today. It'll probably be a little bit longer episode. We're going to try not to do that, if we can. In fact, the people listening know better than we do, how long this is going to be, because they're looking at the slider right now and thinking, "Is this going to last my whole commute?"
Jamon Holmgren:
So, let's get into it. Oh, one other thing I want to mention is if you do find this interesting, you can also use it as a resource to send to people, maybe who are React Native curious, who haven't actually use React Native and they want to kind of know the difference. All right, so React Native and React. They're not the same thing, right?
Mark Rickert:
They're not the same thing, no. React Native is React, but React is not React Native. So, it's kind of like the whole a square is a rectangle, but a rectangle is not a square.
Jamon Holmgren:
Mm-hmm, yes.
Mazen Chami:
We to print that on a shirt, I think.
Mark Rickert:
Throw a little geometry in there.
Jamon Holmgren:
Cool, that's a good idea. Shirts, I like it. So, React Native does contain a full version of ReactJS, so you're actually using ReactJS in React Native.
Mark Rickert:
Yeah. So the code that you look at is going to look pretty similar in a ReactJS project and a React Native project. And sometimes, you can't tell them apart and sometimes they will both just work on both versions, but definitely, React Native contains a lot of extra stuff for the Native's portion of it. React Native is actually kind of a rapper around ReactJS, that it enables a lot of the things that you'll use on a device that a browser wouldn't have access to, things like the accelerometer and stuff like that, photo libraries and things.
Jamon Holmgren:
Yeah. We're going to dive into a lot of those topics, that's a great intro, Mark. One thing also to point out is ReactJS relies on ReactDOM on the web, and React Native does not have ReactDom, it uses its own platform specific, sort of like layer for the UI. And if you're familiar with how ReactDom works, basically it's taking these JavaScript instructions and turning them into browser instructions. So like the browser renders divs and spans and stuff like that.
Jamon Holmgren:
And ReactJS, you inform ReactDom what you want, and then it will manipulate it. React Native has the same thing, but it's using like UI kit on the iOS side and Android layouts and stuff on the Android side. So similar stuff, but the commonality is the ReactJS layer.
Mazen Chami:
I think a good segue talking about the Dom is to talk about styling next. I think, when we're talking about React specifically, what comes to mind is CSS Flexbox. These days, I hear lot of web developers using grid to style their apps. And, these are great to help us make our apps look good and help with the UI and all that. With that said, Mark, do you mind going into what the differences are between ReactJS and React Native?
Mark Rickert:
Yeah. ReactJS allows you to just write standard CSS for the web, and import it into your components and it'll just work. But React Native requires you to write your CSS in JavaScript. And because it's in JavaScript, it's a JavaScript object, you have to use camelcase instead of the dash case that, I don't know, what's a dash case for CSS called?.
Jamon Holmgren:
Kebab-case.
Mark Rickert:
Kebab-case.
Jamon Holmgren:
Yeah.
Mark Rickert:
I've never heard that one before. There's snake case and camel case, title case, but kebab-case. I like that.
Jamon Holmgren:
Yeah.
Mazen Chami:
That's making me hungry.
Jamon Holmgren:
Making me hungry.
Mark Rickert:
Oh. But, I kind of like the camelcase that JavaScript uses, versus the dashes in normal CSS. I think it looks better and easier to read as well, but there are also some things in React Native that don't work, that you can use in CSS. One thing I ran into the other day was a web developer that is working on a project that I'm now on. He had put a [fill 00:09:27] style onto a component. And fill is not React Native compatible, there's no such thing. And so, I get a runtime error and got to go and figure out what he was actually trying to do and recreate it somehow in React Native.
Mazen Chami:
Yeah. Cool. And one thing I want to also touch on is, when we're talking about React, we have a browser without a set width with right. We can multiple different points and you can nowadays use a React web app on mobile devices, on monitors, even TV screens. They now have browsers. While on React Native, we are limited with our width. Obviously, keeping in mind that mobile devices are kind of varying in size these days. But for the most part, if you've used Flex and kind of stick to a standard across your app, it'll definitely Flex across different screens.
Mark Rickert:
Yeah. I feel like web browsers is, you think of it as more of like a four by three aspect ratio. People using the size of their monitors for their web browser, but in React Native, you're building mostly for handheld devices, which are portrait orientation, so you have to think more vertically top to bottom.
Jamon Holmgren:
Yeah. And we had a episode, wow, it's been almost a year ago, it was one of our early ones after we took over React Native Radio, called Styling with Style, it's React Native Radio 188. And, we talk about styling React Native apps in much more detail there.
Mark Rickert:
So, what about navigation? I know in React, I can just create an A link and link it to a new URL, relative or fixed URL. What does that look like in React Native then?
Jamon Holmgren:
So on the web, everything is kind of centered around the URL. And so, you have a URL for pretty much every page, every screen, not every component. But so, you have something like React Router, and React Router will key off of the URL, and bring in different segments and kind of know what to load. In a mobile app, that's not how that works. Although, you do have deep linking and universal links and whatnot, which help to some extent, but you're on a screen, you don't really have a URL for that screen. And, I would also kind of point out a difference in terminology there, there's pages versus screens and that's kind of like a difference in mobile, versus web there.
Mark Rickert:
Yeah. And React Native has a concept of stack navigation that sort of goes with the whole paradigm of the mobile experience, whereas I don't think the web really has that.
Jamon Holmgren:
Exactly. Like, you're not going to stack pages, and pages and pages on top of each other. It feels like you're moving between pages, rather than stacking pages.
Mazen Chami:
I like to think of the mobile stack as a deck of cards. You start with your one card, and then you always bring in cards on top of each other. And then, we have the whole concept of reset, so you kind of go back to the initial one, you can pop some out of the view as you're bringing them in. So, that's usually my best way of kind of explaining that to non React Native developers.
Jamon Holmgren:
I like that. That's very interesting. Yeah. So obviously, routing is kind of a big thing. And you have React Router on the web, you have React Navigation on React Native, and also React Native Navigation is another option. There's a couple other options that we've talked about in the past. And its, the difference is sort of like contained within those libraries and how they approach things. You can do it that way on the web, it would just feel very odd to a web developer to do it that way.
Mazen Chami:
Cool. I think the next thing we could kind of talk about is our state management. So now that we're routing between pages and changing our stack, Jamon, can you kind of highlight some of the differences or potentially similarities between React and React native when it comes to state management?
Jamon Holmgren:
I think what's cool about React and React Native is that state management is pretty much the same. You are using Redux, you're using MobX, MobX State Tree, you can just use bare hooks. You can use kind of just about anything you want.
Mark Rickert:
AsyncStorage.
Jamon Holmgren:
AsyncStorage. Although AsyncStorage is... Okay. So, that's a good one, Mark. So, that is one difference. So on the web, you might be using localStorage or sessionStorage. On mobile, you're going to be using AsyncStorage. And, that connects into sort of like a Native layer of this. But yeah, state management, because they tend to be written in bear JavaScript and that's really the big difference there, is if it's bear JavaScript, it'll generally work, then it will just work. Now, mobile apps tend to be more stateful than web, in that you're not having page reloads kind of tearing everything down, and then reloading everything whenever you go somewhere. So now obviously on web, you can do this as well, but everything is just living out there.
Jamon Holmgren:
And when you make a change, it needs to change things elsewhere in your app. So you often have to make sure that that things are rendering properly, not just on your page, but on other screens that you may have loaded up on these cards, the stack of cards. So that's part of this as well, but it's pretty much the same, Redux, React, and MobX and etc.
Mazen Chami:
Yeah. And I think if you're a ReactJS developer listening to this right now, you're probably thinking, "Hold on, this all sounds the same, nothing really seems different." And you're right, I think we'll kind of start getting towards those differences soon. But if you're using, I'm working on a project right now and we're using Redux toolkit and pretty much when you look at the docs, it's the same, essentially. The only differences is how to set it up and we'll also get to that later. I feel like I'm jumping ahead here. But when it comes to writing the actual code for state management, we're pretty much looking at the same thing.
Mark Rickert:
Yeah. So, let's talk about something that React Native has, that ReactJS doesn't have on the web and that's interactions, like gestures, and Pan Responders and stuff like that. Because, mobile devices have touch screens and sometimes computers have touch screens, but it's very pretty rare. You're usually interacting with a ReactJS application with a mouse. And so, you get a few more things on React Native, as far as gestures go. So, you can detect swipes and multi-finger touches with gesture responder system. It makes things a little more Native-like, to be able to swipe across a photo and have it go to the next photo, where there's no real concept of swiping on the web. So, I think that's one really cool thing that React Native gives us, which is basically just a way to use the touch screen in a way that ReactJS really can't.
Jamon Holmgren:
Yeah. And speaking of gestures and this is changing a bit, but a lot of times web is built for a mouse pointer. And so, these interactions are built for having a pointer with a mouse, trackpad or whatever. Now that is changing, because more and more people are using the web on touch devices. And so certainly, there's a lot of affordances being brought in to the web. So the gap is closing quite a bit, but on React Native, it's built for touch first.
Mark Rickert:
For sure. Another thing that's a little different is permission handling too. We all know that websites can ask for our GPS location, we get the little pop up in there that says, "Do you want to share your location with this website?" But mobile devices have some features that computers sometimes don't, like accelerometers and cameras, permissions to access your photo libraries, and hardware storage and stuff like that. So the permission handling can sometimes be a little bit different, as far as that goes. There's also rules around how you have to ask for permission. And, those rules are governed by Apple and Google's developer agreements. Where to ask for an Android background location, you have to first come up with a screen that tells why you're asking for the background location. And not only that, you have to ask for a regular location first. So there's some hoops that you have to jump through, in order to actually be approved by Google to go into the App Store, if you're using certain permission features.
Mazen Chami:
Yeah. Those features can be very tedious. But when we come into the age that we're in now, with privacy and all, it's very important to make sure we include those. And, I think the Google stores and the Apple Stores are kind of hunkering down on those and making sure that as a developer, we're setting those permissions right. And notifying the users, why we will be accessing their photos, versus camera and all that.
Mark Rickert:
Yeah. We definitely want to be good citizens when it comes to user data, and privacy and stuff like that, so you always ask the user first.
Mazen Chami:
Totally. So, the next topic I'd like to kind of dive into is kind of the ecosystem between both of them, if either of you would like to kind talk about this, but one thing I'd want to bring up is there's a lot of similarities here when it comes to what we're talking about, when we're talking about packages and different libraries that are out there.
Mazen Chami:
Pretty much, any package you find that is pure JavaScript can be used across both of them. And then, there's also some other slight differences.
Mark Rickert:
Yeah. And when you're creating a ReactJS project or a React Native project, we're using kind of the same tools with NPM modules, and all goes in the node modules folder. The ecosystem kind of looks the same from a file hierarchy point of view, right?
Jamon Holmgren:
Yeah. It sure does. Now, you do have Android and iOS specific package managers, which are CocoaPods, and Maven and-
Mazen Chami:
Gradle.
Jamon Holmgren:
... Gradle. Thank you. I was blanking on the name. And so, those do get pulled in. But even like React Native, has a way to kind of automatically pull those in with a third party package that is brought in through NPM. So it's sort of this like, it feels a little cobbled together, but it works pretty well in the end, where it's kind of marrying all these different ecosystems together. There are packages that don't work on React Native or vice versa. And then, you will have a React Native equivalent, usually prefix by React-dash-Native, dash whatever.
Mark Rickert:
Yeah. I've seen a lot of times where a developer will find something that it's already made for iOS or Android. And they'll say, "I want this in React Native," but it already exists as a CocoaPod, or as a Gradle dependency. And so, what they'll do is they'll write just the JavaScript translation layer and then say, "Use this CocoaPod and use this Gradle package." And so, it makes the React Native specific version for this feature that you're trying to implement, for actually pretty lean and relies on the native application packages to do all the heavy lifting.
Jamon Holmgren:
That's a great point, Mark. And one of the things you have to watch out for is sometimes those have iOS implementations, but not Android or vice versa. So you might say, "Oh, I want it to be React Native," but it might be React Native, but only supports iOS or React Native, but only supports Android. That's changing, like for the most part, people are supporting both now, but they do literally have to write two implementations when there's a native integration like that.
Mark Rickert:
Yeah. In my experience, Android has always kind of been a second class citizen here, where someone will create a React Native library and say, "Doesn't support Android."
Jamon Holmgren:
Yeah. That does happen. Let's talk about performance. So obviously with web, you have a browser, with React Native, there's no browser. I mean, you can certainly embed a browser inside of a React Native app, like if you want a WebView somewhere, but you don't have to have a browser at all. React Native has its own code to like render the UI and stuff. And it uses a native UI, so you don't have a browser wrapping it. That comes with some performance benefits, you can certainly see some performance benefits over a website. And that's why sometimes people are like, "Well, I would build a website, but the performance is just not there, that's why I went React Native." And now, performance obviously is a priority on the web as well and they're making it better all the time, but I would say that React Native is a little closer to the metal.
Mark Rickert:
Yeah. We talked about performance in React Native Radio, 217 and 218, where I was a guest.
Jamon Holmgren:
Mm-hmm.
Mark Rickert:
So if you're really interested in React Native performance, you can check out those two episodes.
Jamon Holmgren:
You also have the option to drop down into Native modules, which we've talked about in the podcast as well. And the cool thing about Native modules, you get full Native speed, but within a React Native app. So we recently released an episode talking about React Native Colo Loco, which allows you to write a Native module right alongside your JavaScript stuff.
Jamon Holmgren:
That's a difference between web and mobile. You can't do that on web. You can't write like a C++. I mean, you kind of can like with some of the tools, and certainly like Wasm and stuff are coming in to WebAssembly or coming in to make that better, but it's not there yet.
Mark Rickert:
So when it comes to distributing your apps, ReactJS or React Native, they're a little bit different. Well, they're a lot different. You can write a ReactJS application, and basically deploy it anywhere you want. There are thousands of server hosting companies. You can run it locally on your machine, if you just want to run an internal web server or something like that. All you need to do is spin up a web server somewhere, and you can deploy a React application, but React Native relies heavily on the walled gardens of Apple and Google ecosystems. You pretty much have to distribute them through those two different stores. And with that comes a lot of headaches around certificates, and provisioning profiles and signing everything to make sure it's all going to upload and Apple's going to accept it.
Mark Rickert:
You'll have review processes, where you have to wait for Apple or Google to either do some sort of machine type algorithmic determination of whether you're doing anything wrong. Apple and Google actually do have a team of human reviewers that will actually load their app up onto a physical device in batches to see if they crash when they start up, to see if they're asking for permissions properly and that sort of stuff. So, there's a lot more time delay when it comes to distributing React Native applications versus React. You can just upload a new version of your React app to your web server and is live immediately, whereas React Native takes a little bit more time.
Mazen Chami:
Yeah. If you are a React developer, this is probably one of those big differences, and Mark just listed a lot of steps and hoops you have to jump through. One thing I usually tell product team and all that, "If you are transitioning into a mobile app, be patient, plan ahead." And you could probably hear in a Mark's voice. I think I heard it maybe because I've been burnt by it too. You probably will not get your app accepted right away.
Jamon Holmgren:
Mm-hmm.
Mark Rickert:
No, not on the first try.
Mazen Chami:
If you get it on the first try, please us know what your secret is, but be patient when it comes to that process, for sure.
Jamon Holmgren:
Can you imagine if you had to run your website by some opaque committee that you don't even know what's going on. It's just very foreign to web developers, but...
Mark Rickert:
Yeah. There is a few ways to actually increase your development cycle times for React Native. And that is, once your app is initially approved, you can use features like CodePush. There's a couple different services out there, where basically you can host your JavaScript bundle on a web server. And when you go to update it, you just push up the new JavaScript. And if none of your native features have changed, if you haven't changed any native code or added any new modules that add native code, you can just update your JavaScript to fix small bugs here and there, and rely on a CodePush functionality to deliver an update to your users apps, instead of having to go through the whole apps of middle process over and over again.
Jamon Holmgren:
Yeah. And, that kind of brings up one of the big differences here, where with a ReactJS app, you are downloading the React bundle, like the JavaScript files, on request. So when you go to that URL, it will download it to your browser cache, and then you're running it. So the next time you go there, if the cache is expired, it will download the latest version, whatever the latest version is. And so, a web developer will just be like, "Well, why don't you just have a different version available on your server?" That's because you don't really have a server. I mean, you have a server, but you don't have a server serving up the JavaScript files. Those live inside of your app, which is downloaded from the App Store or Google Play Store when you download the app. And so, that's what CodePush sort of replaces.
Jamon Holmgren:
It allows you to update that JavaScript bundle, but Google and Apple will not let you update native code that way. You have to go through the App Store process, in order to replace your native code. So if you do have any native code updates, as Mark mentioned, you'll have to go through that process. Often that's not necessarily the case, you can certainly just update the JavaScript side of things. You're working a lot in JavaScript, you're not doing a lot in the native side. So, that tends to be relatively straight forward. I did a live stream a while back on React Native Live, my Twitch stream, where I explored expo updates, which is a way to kind of push updates to React Native app, that worked really well.
Mazen Chami:
That's an exciting feature that's coming out, for sure. Let's move into tooling. I'll name a couple that I think are quick to highlight here. We did mention that React Native is pretty much React underneath the hood. So when we talked about state management, we said pretty much a lot of that stuff is the same and that also goes for hooks. You can use all the hooks and all the latest from React, I believe it's 18 and above. So, all that's there on both of them. If you are a developer, that's inclined to stick to TypeScript, you can use those on both of them and I think you should, as a TypeScript fan over here. And then, same similarities again, Mark mentioned it, if you're looking down at your code structure, you pretty much will have the same thing. You'll have your node modules file, you'll have your Babel file, your VS Code, package.json. So, a lot of similarities when it comes to most of those toolings that you're used to using on the web, versus and on React Native.
Mark Rickert:
Things like ESLint works, Prettier, all these tools that web developers are familiar with, we get the benefits of those in React Native as well, because it's just a package.json file and it reads in NPM modules. You specify them exactly the same way. So, there's a lot of similarities there that will make a React Native application look kind of familiar to a ReactJS developer. But I guess, maybe we should talk about the JavaScript engine, because that's something that is different. I guess, you're relegated to whatever JavaScript engine the browser provides to you, which Chrome uses its own JavaScript engine, Safari has its own. But I think on web now, the browsers are starting to consolidate a little bit more and it's not as diverse as it used to be, where you used to have to create specific versions of things for Internet Explorer.
Jamon Holmgren:
Yeah, exactly.
Mazen Chami:
Those were the days.
Jamon Holmgren:
So, the most famous JavaScript engine is probably V8. And, that's what's used in no-js, it's what's used in Chrome. It's used in a lot of different scenarios. But that's tuned for web, it's tuned for kind of the needs that it has. Safari actually uses JavaScriptCore, JSC, which is also used in React Native. At least right now, it's the default. And then, Facebook is actually working on one called Hermes, which has been deployed and it's now kind of, I don't know, I guess, beta level. And it is really cool, it works on IOS and Android. And, it is tuned for what React Native needs out of a JavaScript engine. So, I think that's an important difference. Although generally, that's pretty transparent or I guess, you would say opaque to you, you don't really need to think about it too much. But it is something to keep in mind that you are using and you do get to actually choose what JavaScript engine is being used under the hood.
Jamon Holmgren:
We also, one of the other big changes for the tooling side of things is Metro versus Webpac, or Rollup or any of these other tools that you might use on the web. You can use Babel, Rollup, you can even use Webpac on React Native, there's Re.Pack, which is a Webpac version of the React Native bundler. But the most common is Metro and Metro is limited, but also relatively straightforward to use. It's kind of just the vanilla. It works generally. When it doesn't work, it can be kind of a bear to figure out how to fix it, but it's a pretty decent solution, at least for now. And then if you need all the power and complexity of Webpac, then you can go Re.Pack. But on the web, you'll be using Parcel, and Webpack and other bundlers like that, there's actually a big bundler war going on right now, where people have their camps and want this and want that. Over on React Native, generally speaking, people just use Metro and move on.
Mark Rickert:
Is there anything other than Metro?
Jamon Holmgren:
It's just Re.Pack, is kind of the big one. There was one called Haul, that was kind of an alternative. And that one was deprecated, Callstack came up with that one, and then they came out with Re.Pack recently.
Mazen Chami:
And then, they hauled it away. It's fine.
Jamon Holmgren:
They packed it up and they hauled it away. So, Metro versus Webpack, that's something you do have to keep in mind. Because when you're deploying it, you actually have to bundle it up into a JavaScript bundle, and embed it in your app, which Metro obviously does by default.
Mazen Chami:
Yeah. And then going into end-to-end testing, this is also a situation where we have core differences. Because if you could think about it, we're talking about a browser where it's pretty straightforward, you can go to several URLs and have that interaction. But then on the React Native side, you have physical device, devices because multiple platforms and potentially different screen sizes you want to test. So on the React Native end, we have Detox and Appium, which I believe are widely used across the ecosystem. And then on React web, you also have Cypress and Selenium that are used. So, different packages out there for end-to-end testing. But I believe at the end of the day, you're still writing the specific tests that you would need per your device or screen size.
Mark Rickert:
Yeah. I remember when Appium first came out, it was a revolution because you could actually control the simulator and step through things in the simulator. And one thing that you have to, I think, keep in mind is that you have specific things you have to do, in order to support testing on Native. You can't just like say, "Oh, I want to select this specific ID," you have to give a test ID to your components, in order to find them. Now, it has evolved a little bit more now, where you can say select the button that has this specific text in it and press it. But that's, I think, more of a recent thing that's come into Appium.
Jamon Holmgren:
So on the web, you have the React Debugger, which is a great tool for debugging React apps. There's also the React Native Debugger and there are some differences between them, but they essentially do the same job. And so, you can use that as well. And just connect it up to your React Native app, and there are a lot of really cool features there. Generally speaking though, I will say React Native tools, Debugging and otherwise are behind react web. There's just not. There aren't as many people working on them, they're getting better all the time. But certainly, if you're used to sort of a pretty incredible level of tooling that exists for React web, you may be a little bit disappointed in where React Native tooling is. It is getting better, like I said.
Mark Rickert:
Yeah. And you can also use the Native Debugging tools as well, if you're building in Android Studio or iOS, they have tooling where you can go and look for memory leaks and stuff like that, orphan components and stuff. You can find all that stuff using the Native tools that you don't have access to obviously in ReactJS. So when I'm going to write a React Native application and I want sort of a companion site on the web with a lot of similar features and stuff like that, let's talk about what it looks like sharing code between them. Because I think this is a really cool evolution of the ecosystems, where we saw these two separate things that are kind of like each other, and now they're coming together in a way where you can really just write it once and deploy everywhere, in essence.
Jamon Holmgren:
Yeah, totally. And I think this kind of gets at the heart of why React Native is so, I don't know, I guess attractive. Like you have Flutter and some of these other things, but React Native really has this dialed. So I guess, my question to you is, are they compatible, like a hundred percent compatible?
Mark Rickert:
Yes. Well, no. They're sort of compatible.
Jamon Holmgren:
Yeah.
Mark Rickert:
They're sort of compatible. React Native doesn't allow you to use things like divs and spans, and
tags, and A links and stuff like that. And, it can be kind of confusing at first for someone coming from the web to see views, and text blocks, and scroll views, and flat lists and stuff like that, because those don't really exist on the web. They're not really supported in React Native, these divs and spans and stuff.
Mazen Chami:
I would kind of argue that they make more sense. I think seeing a view and a text, I understand we have P which sounds like it's a paragraph, H1 header, but I feel like text makes more sense, view makes more sense. Probably a topic for discussion another time.
Mark Rickert:
Yeah. The tags are a little more declarative.
Jamon Holmgren:
Yes.
Mazen Chami:
Exact, yeah.
Mark Rickert:
Yeah.
Mazen Chami:
Yeah. I feel they make more sense as to what they are flat list, you know what it is, a scroll view, you kind of know what it is. But then again, there is the difference where on a web you're probably always scrolling essentially.
Jamon Holmgren:
Yeah.
Mazen Chami:
Yeah. So there are those differences, but when it comes to your code, kind of everything outside of the render block, it's pretty much copy, paste. We talked about state management being the same, you can use your hooks and all that, potentially some slight differences because of some libraries you might be using that are React Native specific. But I would say for the most part, not a hundred percent, you can copy, paste everything outside of the render block
Mark Rickert:
For sure. And, there's a really great library that gives us sort of a translation layer between React Native and React Web, it's called React Native-web, oddly enough. And I think we've, all three of us, have used this before in a project, where we're sharing components between React Native and the web. Clients want a reusable code that they can deploy everywhere and React Native-web actually makes it really easy to do this, where you just write React Native syntax, using views, and texts and stuff. And then, React Native-web is a translation layer that converts everything to divs and spans and converts the styles over to display properly on the web. It's actually a really powerful tool and I've used it myself in production applications and it works great. You just write a component in React Native, and set up all of the web stuff for the web version of it, deploy the web version and you get something that looks almost exactly the same on the web.
Mark Rickert:
When you're doing this translation with React Native-web, it sometimes can get to a point where you're like, "Oh, I need to do this thing and the only way to do it is with a div," I don't know, I don't know why. But you can always take advantage of the platform specific extensions, where you can name something myfile.web.txs or .js. And then, the bundler will look at that one specifically and only serve that one up for the web. And then, you can write your Native specific implementations in the iOS and Android versions of that file. So, there are ways that you can share code between components and specify when you need to just break out into web specific, and use web compatible components and things like that. So, that's a really neat way to keep all your code base in one project and still be able to deploy web and mobile specific versions of a component.
Jamon Holmgren:
Awesome. So this was, I think, a good overview for people of what the differences are between ReactJS and React Native. And I will say like, here at Infinite Red, we specialize in React Native for a reason, it takes... As a React web developer, you can learn React Native and get decently productive with it in not very much time, like we're talking a week or two, you can be deploying pretty good code. But in order to really deep dive into some topics like performance, and Native integrations and stuff, often that takes years to learn. And that's kind of one of the reasons I like React Native because React, I feel like I kind of got to a certain point, I was like, "Okay, I'm a little bored, I want a little more of a challenge."
Jamon Holmgren:
React Native, it feels like there's always a challenge. There's always something really, really... You can deep dive there. And one of the other big things I want to mention here is that the ideas from each community really help influence the others. So React Native is the intersection of three communities, iOS, Native developers, Android Native developers and web. And there's really, really cool ideas on all three of them. And having that kind of collision is really kind of like, it's the best of all worlds.
Mark Rickert:
For sure.
Jamon Holmgren:
Awesome. Well, we don't have time for a weird bug today, I'm sure Mark probably has four or five that he's run into. He always sends-
Mark Rickert:
Just waiting in the wings.
Jamon Holmgren:
Yeah. He always seems to send us weird bugs that we can put on the program, which is awesome. But let's go ahead and wrap up. Where can people find you, Mark?
Mark Rickert:
You can find me on GitHub at Mark Rickert, I'm also on Instagram, same, Mark Rickert.
Jamon Holmgren:
And Mazen, where can people find you?
Mazen Chami:
@mazenchami.
Jamon Holmgren:
Perfect. And you can find me @jamonholmgren. You can follow React Native Radio on Titter @ReactNativeRdio. Thanks to Mark for joining us again today and helping us on this topic.
Mark Rickert:
Its always fun.
Jamon Holmgren:
Yeah, you're always awesome. And as always, thanks to our producer and editor, Todd Werth, OUR assistant editor and episode release coordinator Jed Bartausky, our social media coordinator, Missy Warren, our designer, Justin Huskey, and our guest coordinator, Derek Greenberg. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/reactnative. Special thanks to all of you for listening to today. Make sure to subscribe. We are called React Native Radio, as you know. And reminder, that we are hiring at Infinite Red, React native engineers. If you're a senior level react native engineer located in the U.S. or Canada, go to careers.infinite.red and we'll see you all next time.