React Native vs Capacitor: Performance, Flexibility, and Business Impacts - RRU 262

when tests are delivered and approved. In today's episode, we have a very special guest so that we can talk about React Native versus capacity just as an even larger interro for those of you that may not know what the pastor is is yet another technology that allows you to transform your web code so that it can run all mobile as well, similar to how React Native does it like in terms of the final product, but they.

and whatnot. Now, I do want to tell the audience I've been doing React Native for eight and a half years. I the last Capacitor or Ionic project, I should say that I've done was about that long ago. So what I know about Ionic and Capacitor has been from a

distance or spinning up a little like play apps. I haven't built apps in Capacitor that are that are like really significant, so I always have to put that caveat out there like that this is, you know, like this is something that I want to make sure that I that I do a good job of comparing the two and and don't just lean on my own like experience and and and even my own what my company specializes

in and that sort of thing. With that said, in order to like prep for this episode, I actually reached out to my friend Jessica Sachs, who used to work for Ionic, and I went and I actually chatted with her and I said, hey, look, I really want to make sure I've got this right, and and we talked for a while about what, you know, what Ionic and Capacitor really like, what the state of the art is in twenty twenty four. And I think, I, uh, you know, I I think I'm I think I'm well well armed

for this. I think I can probably do a pretty decent job where she won't be like cringing hopefully if she listens to this episode.

Ionic is the company. Ionic Framework are the UI components that also come along with Capacitor because they depend on capasitor, And then Capacitor itself is just the the build pool that can transform your web code into mobile applications, but it doesn't come with the pre done UI components that translate to the native forms.

of like building a business around it. And then Capacitor is really the technology that they created in order to have per performant like as performance and capable as possible bridge over to the native side. So yeah, I think you did a good job.

really interesting. And I don't know if we're even going to get into it, because I think perhaps we would need a deeper understanding of the rest of the ecosystem to even talk about that, but I was really curious to understand if app flow and their live deployment picture only work with Capacitor or Ionic, or if it actually worked or React Native as well, because from their website,

I see that they have logos of other pools. So if you go to their website for app flow, which is a product of the Ionic company, then it has a logo for a capacitor are you, but also for React Native and Cordora, So I thought that was interesting.

of this technology. But unlike Expo, which is double down and React Native, they are they seem to be adopting other technologies and providing solutions across the board, so they seem to have a wider I guess umbrella across you know, React Native and and their technologies and and whatnot. They do provide things like, yeah, the c CV service and and and more. So, Yeah, it's it's an interesting company for sure, And I've liked all the people that I've

talked to there. They're good engineers. They seem to understand, you know, what us developers go through and whatnot.

build something in house and then use that. It's not actually that difficult, I would say, especially when we've done it a few times. But of course, building all the features out that you might expect from an over there update perspective, that's where it, you know, where like you get into it's like a deep rabbit hole there.

want to use the app, you need to update. And that's completely different from what we have on the web, where we just assume that all users are in the latest versions, but those over the air updates they fix this problem, right, But the complexity comes from the bureaucracy of getting approval from the play Store and the App store from Apple because from what I understand, the thing that they are trying to prevent is companies pushing code

that didn't went through their official review process, right, So how do you make this all out?

native code. This is just like JavaScript that's getting uploaded. So it's really no different than in a browser loading a new website, right, like you can just jump to

a new website. But Apple and Google seem to have different rules around browsers versus other apps, like they seem to really kind of differentiate between the two, and certainly they have a financial a vested financial interest in disallowing things that act like other app stores and Epic has like had these massive battles with Apple around we should be able to provide our own app store the inside of the iOS eco system, and so you just kind of keep going down this rabbit hole for now where

we are is they allow it as long as you don't change the significantly change the like core functionality of the app, or introduce things that you know, like you know, get around the app store and rules. And the problem is that there's really not a lot preventing people from abusing this. So when it gets abused, not if, but when it gets abused in that kind of high profile way where someone ships over the air and update that

like brings in something that Apple would consider egregious. Then there's probably gonna be a battle around this and they're gonna start saying you can't do this. So it's something that I'm keeping a very close eye on. It's like Evan Bacon from Expo correctly says that over there updates is one of reac Native's killer features. It's also, by the way, Ionic capacitors killer feature too, because you can

do the same thing there. But we're always a little bit leery of like like over selling that just because Apple could come in and put the hammer down. If that happens, they're going to have a battle on their hand though, and they're already fighting some battles you know, in the EU and other places including the US. And so this is a whole podcast episode topic. I could go on forever about it, but it is. There's a lot more to this story, but it basically is like, yes,

it's awesome, we use it. We try not to do it in such a way that like if Apple came in, they would get really mad at us, just because they unfortunately are the gatekeepers here and you know, don't don't rely on it forever, Like that could be problematic. Now there is obviously the other way for submitting updates, and we can always send in a new new build and then, you know, two weeks later, get a rejection that gives you no information about why it's rejected, and then have

to guess on how to fix it. I'm not bitter at all. I'm sure you can't tell.

I guess if In from the Hermes team was listening to this, he would cringe because he knows all the reasons that that's wrong. But that's basically how I think about it is that it's in those terms, but it's still kind of JavaScript under the hood, you know, it still has the same kind of characteristics and whatnot. Under the hood, it's just been compiled from JavaScript. So it's a bundle, it's a file. It's a single file. Like in most cases and the vast majority cases, it's a

one file. You literally just put it up on an endpoint, and your app downloads it just like it would download any file, replaces it or puts it in a certain spot, and then starts using that bundle reloads, you know, like it starts using that bundle instead. So that's essentially how it works.

what developer experience. Certainly, those are a big part of it, and you know that's something I've searched for my entire careers, better solutions for doing those things. However, these apps are usually for businesses, and these businesses have constraints, and these constraints matter. So when you look at things like Native versus React Native, or PWA's versus Mobile at All, these all have these questions wrapped up in them around the business parts of it, and Ionic and React Native both

approach this problem very pragmatically. They come at it like, hey, look, we all want good experiences, but we also understand that we have constraints and we want to be able to ship quickly with technologies that we all know and that we can share across multiple teams. We want to enable the biggest cohort of developers, which is web to build and deploy mobile apps. So they both really approach that

from that standpoint. Now where they differ is where they make these trade offs and what they're willing to trade off. So I would see it in some ways as there's different levels of of abstraction here. So obviously you can build a native app. You can even go lower and than a native app like like you know, you're you're you're just like writing like super low level like c

or whatever. But you can you can write what you know Swift in Cotland, you can build in the native SDKs, and that gives you some benefits of like being able to customize and really fine tune at that level your apps. But the business problem is that your web developers are a little bit intimidated by like hey, like like hey, build me, build me a mobile app. In both Swift

and Cotland by the way. You know, this isn't like a React developer who's just done JavaScript, you know, and Typeescript, Like they're going to have to learn a lot of stuff to do that. Additionally, if you want to be like, Okay, I'm going to build out my team of iOS developers and I'm going to build up my team of Android developers. Now now you have three teams, three different subcultures will emerge. I've seen it every time, like they're working together all

the time. And anytime that you have teams, I mean my own team, like you know, we're thirty some people. We now only do React Native, but at the time when we started, we did Elixir, we did React Web, React Native, we did a few other things too, And those subcultures would emerge. They would hang out together, they would talk together, they would like share knowledge together, but

they wouldn't do it across their teams. So now you have three different I remember talking to Square Space for example, and Square Space had like in their office they had I think in New York, they had like a pod for their Android developers. They had a pod for their iOS developers, they had a pod, huge pod for their Web developers. When they went to React Native, and this would have been the same if they went to Capacitor.

They were able to re architect their literally their office, like like remodel their office, to combine those into a single team that was divided up in different ways, and they could all talk together, they can all help each other, et cetera. And so when you're talking about the trade offs that we're talking that we're making here, this is like one of the key things about Ionic. And I'm gonna say, whenever I say Ionic and Capacitor, just assume I'm talking about the whole thing. I don't want to

have to I'll just say Capacitor. I'll just I'll say capastor, even though that's like one chunk of it. All right, So anytime you're talking about Capacitor and reac natives, that's the major benefit. You bring in all the knowledge of your web developers, all the a lot of the tooling, not all of it, but you bring in a lot of the tooling. You bring You can share code, like if you have a validation function you know, something like that, or even just a library that you use you can

use across the board. You can share types if you use Typescript, like you can say, Okay, you know I want to use I'm consuming this API and it has this type. Okay, well, our iOS app, our Android app, and our web app all share the same types, and you can kind of go from there. And every time I see this happening at any company, it's incredibly striking how compelling that story is. It's the business case of it, and it's the organization, it's the human element that really

really changes there. And then there's a speed element as well, because you're building two to three sometimes plus platforms at a time rather than rebuilding it over and over. And I've done the rebuilding over and over. I've done the web, and then now we have to build an iOS app. And now turns out people actually want androids. Okay, we

want Android, let's put it. And you're having to build it over and over and over and solve the same problems over and over and over, and it just feels like a waste of time, Like why are we doing this over and over? Like build it once or at most like build it twice, and and you'd have web and then mobile. Right, So Ionic really want to lean wants to lean toward let's build it once, like let's use all web technologies and whatnot, so they will like

the technology itself. For those who don't know capacitors using a web view like they have, they have native bindings, but it's not for the UI, Like the native bindings are at the S or they're at the API level. So you want to like get your location, or you want to get you want to access the accelerometer, or you want to like have a little you know, like have the phone vibrate or whatever hapic feedback, then they'll

provide native bindings for those. But then the UI itself is just rendered in a browser, so it's all the normal technologies that you're used to, like like HTMLCSS, JavaScript, all in the browser and you can use all of your web knowledge within that. React Native is not going to do that. React Native uses just JavaScript and when you it has all the same like native bindings for all the device features, but the UI layer is actually building native views. And so that's the main difference is

on capacity. You're going to have a WebView running with a browser and then on the React Native side you're going to be running native views. But there's trade offs there because a browser, even though it's heavier, it's sort of like like Electron for example, brings with it all these benefits of using the powerful web technologies that we've developed, where React native has to re implement some of that stuff and and like like make for a similar feel there.

So it's really at the business level, and then you have to start thinking about the tech level and the trade offs there and how far are because there are there are limits to how far you can go with a web view, like like at some point that like high fidelity buttery is smooth kind of feel that you

want from an app. You may hit it, You're you're gonna you're gonna probably hit a ceiling with with ironic, but that ceiling is a little higher than you think, and it also is uh you know, it's it's not every app needs like the buttery smooth feel because maybe you're you're just really tapping between screens and stuff like that.

it actually is. So if you're afraid of trying to build it once and ship it everywhere because you think that for some reason your application has a particular feature that is just not going to work with trying to use those hybrid technologies in most scenarios, you're actually wrong.

In most scenarios, you can actually build it hybrid and you're not going to regret it, And the chances that you're going to have a feature that is simply not supported unless you're native are extremely small or perhaps even an existent, because I think you can still mix and match right native code with hybrid.

or Cottlin and just drop it right into the middle of your Reactnative app and it works like you can do that. So that's uh, we're starting to get into some of the trade offs here. Ionic has a lot of benefits and I can go into some of those, including things like it's much easier to set up than React Native. I mean, that's just every Reacnative will admit that. It's true, it's like so much easier. But this is one place where you're going to hit the ceiling sooner

with capacitor. It's you're going to hit that level because you can't then drop into native when you need to. Now capacity devs will say how often do you actually need to do that? Like not very often, And it is true, it's not very often. But you have that extra tool to reach for with React Native, which you would not. And that's why I think I've been very

happy with Reacnative. I feel like it really hits that kind of sweet spot between all the convenience and whatnot with the potential for customization.

like anything Bleeding Edge, Brand New whatever. React Native itself might not have a binding for that, and that's fine, like you could. You know a lot of times when something comes out, people want to play with it and you'll find a third party library that pops out in the next week or two. Like it happens all the time. But I have said this for many, many, many years, and I'll keep saying it until I'm blue in the face. Here's the deal. React Native developers need to not be

scared to write native components. They need to not be scared of that. It's really important. I've thought about even making my own course. Like, take this course and you will no longer be scared to write your own native component because if some new feature comes out WWDC or whatever and you want to take advantage of it in your app and you don't want to wait on anybody else to do this, just build it yourself. It's not that difficult, it really is not. And so yeah, there's

there's really there's really no leg time. No more than really, I mean like native apps all the time will leg on adding new features just because of engineering time. Like you got to implement it, you got to add it in right, No more than that, Like, and if you really really want to do it, you just build a native and integrated into your app. Now, if it's something that React Native should be taken care or taking advantage of, then you may wait a little bit for the core

team to kind of catch up with her. You can obviously, it is open source, so you can contribute to React Native and kind of help that process. But those are kind of few and far between. It's rare that something actually affects the core of sure all.

They say that React Native takes up learn once, write anywhere, and Ionic takes up right once, run anywhere. And basically what they're saying is that the differences with React native. You learn Reactnative and then you use it to create screens specifically for Android and specifically for iOS. And in contrast with Ionic, you don't think about either iOS or Android. You just write it once and you trust that they're going to package and that single build is going to

work for Android and iOS. Which sounds cool, but then it brings so many other questions from my mind, like this example that we were just talking about WWDC, like Vision os two only exists in the Apple ecosystem, Like it's never going to exist in the Android ecosystem, So how do you build it once if you have something that it's only going to exist in a particular ecosystem.

is just wrong. I think it's just wrong based on literally like almost one hundred apps that we've built over the last nine years, like big ones, like tons of them. And we started out with React Native version zero point eleven. It's now up to zero seventy four or seventy five depend when this comes out. And here's the deal. Like the very first apps that we started with two parallel projects just to try it out make sure it worked, we got over eighty percent code reuse in that very

first project. It was like close to ninety percent code reuse between iOS and Android. Over the intervening years, we have regularly hit one hundred percent code reuse or ninety nine percent code reuse like once in a great while, we'll have a little if platform OS is Android, do this otherwise, you know. Or we might do the extension thing where it's like index dot Android dot tsx, index

dot iOS dot tsx and it'll render that. But it's the vast majority of the code that we write is write once, run anywhere, vast majority, And I think it's done more harm than good. It's to me, it's been literally, I think that slogan is just a kind of lower expectation is all it is. And so then people will then take it very seriously and say, oh, well, we have to write every screen twice anyway, so why would we use react native. It's not true. You just don't

like in real life, you know. Ninety eight percent, I'll say ninety eight percent. I'll be the developer lowering expectations here. Ninety eight percent of your code is going to be the same. It's gonna be the code that you're going

to use one component for both. And usually when you're making a differentiation, it's either because of platform differences as far as what they support, which you would have to do anyway in Ionic, or or it's differences that you want to like, you want, like Android users expect this to be different, you know, so you're kind of like catering to your user base. iOS and users expect it to be this way and Android the other way. So in that case you should write something different there. But yeah,

this is a little bit of a rant. I'm sorry, but like the whole learn once write everywhere to me is a it's it's not a good slogan. Expo XPO talks. You know, Expo says, create universal native apps with React that run on iOS or Android iOS in the web, so they I think have a better tagline. Uh. And to me, Expo kind of gets this a little bit better than you know, like meta engineers are brilliant, they're incredible engineers, not always the greatest marketers. That's not what

they're you know, there for. Uh and so sometimes these things, you know, like, it's a very engineer type slogan, not one that I likely gotcha.

hundred and twenty times per second. It's not going to update four thousand times per second. Even if you could, you know, a human could perceive that. So within that, like if you're in the games industry and you're working within like frame rate you know windows, you you kind of understand around like like what matters and what doesn't. If you're doing some work and then you know, you you make the frame window like you're in that frame window.

You're good, Like you're you're fine. Now, there may be some other things that matter there, like battery life and stuff, and certainly we think about those things, but it's not the perceived performance of the app, like that's not that's not called that's not affected there. So that's number one, like what matters. It's a there's a lower bound of like it's got to be at least there, like we got to hit the frame, you know, we can't be

skipping frames. And then the other part of it would be like what if you start getting into really heavy screens where it is not possible to like start hitting those those frame rates, or there's other things that are wrong with it. And there's just one really important rule before we get into the technical limitations, which is you can write poor performing apps in any language anywhere. I don't care if you're writing C plus plus, I don't

care if you're writing handcrafted assembly. You can write it in such a way that it's it's poorly. It performs poorly, and because of that, there's a variety of ways to approach this. But you have like compilers that will that will and like like JavaScript engines that will take the the code that you write and try to optimize. They'll do things like inlining functions, they'll do things like you know, memoizing things and like shortcuts and whatnot, and those can

very much help. But where capacitor hits the limit is the limit of the browser that is in the system, so the WebView, the web engine, so that brings with it. It's a certain amount of overhead itself. And then especially on iOS it's usually not as advanced. Google seems to take their web view a little more seriously and the engine a little more seriously, so the Android side seems to be a little faster. However, there's still limits there because

you know, it's a web browser. So the performance of Ionic is going to be a cap. At some point you're going to hit that or capacity. You're going to hit that cap, you're gonna hit that ceiling. React Native also has a ceiling because of and this is kind of like influx right now, because the new architecture. But there is a ceiling because of the the JavaScript bridge. But there's a number of ways to get around that. So one is that you can run more things on

the native side. So animations, for example, you craft the animation, you send the information over the bridge, and then the native side does all of the animating like you don't even it doesn't even hit the jobscript side, So you just have like everything running in the native side. And then obviously if you need to, I always tell my developers like, don't be afraid to drop in native if you need to. But vast majority of the time, just

the universal truth is someone has to care. If someone cares about performance, you can get so much further before you hit the limits of the technology itself. So someone caring and spending the time will go super super far. And then yeah, the React native apps are native apps because you can drop in a native any time you want, and you can build anything you need to. So there should never be an excuse for poor performance in a

React native app. There might be an excuse for poor performance in a capacitor app, And that's okay because the way that that Jess kind of described it to me when we talked about this is that she really recommends Ionic and capacitor apps for more like document focused apps, like apps that are more like around content like that.

If you're talking about app focused apps like like you know that need like really smooth animations and scrolling, and you know think something like I don't know, dual Lingo or Instagram or something like that, then it makes sense to maybe go with something you know, something else and Reacnative of course would be a prime thing there. But performance really isn't an excuse with reacnative. There should never be something that you can't achieve with REAC native in

as far as performance. And I will say just a shout out for my own company, Infinite Read, if you have trouble hitting that performance, then come talk to us, because there's no reason why you can't get there, and certainly if you have us built alongside you all the way, we'll teach you how to how to build perform apps like that. That's part of what we do.

the business needs. And I mentioned this before. Now, if you if you're using something like Angular and you would love to continue to use Angular, you know, and just kind of keep that rolling throughout your your organization, then you can consider something like Ionic and capacitor, because that would be you know, that would be a possibility there. If you are using React. I know that there's Ionic React, but I think you should strongly consider React native just

because of the flexibility. There are some other like like view Native and svelt Native and stuff like that try to build on top of React Native However, they're not the greatest supported, you know, generally speaking, So I would say if you if you're insisting on using something other than React, then yeah, consider consider Ironic and Capacitor. If you're using React, use well, really Expo. You should be really looking at Expo and uh, it's gonna be hard

to beat the the combination there. I think it really makes good, good trade offs. I'm I'm still a huge fan of React Native after all these years, which normally I move on to another technology after five years, and this is like almost double that now, So yeah, very much. I think that's that's a kind I think where and you know, I can help you make that decision if you if you're a company, you know, talk to me.

I'm more than happy to chat about it. And uh, but I always try to I always try to have like you know, I I don't want to be unfair to these other technologies. There's reasons, there's it's as like every that you know, the joke is like it depends right, like there's a it's a it's a trade off discussion

and whatnot. And for my particular values and what I want to hit, you know, business wise as well as technology and developer experience wise, I really think React native makes sense, but obviously there are totally valid reasons to use something like capastor.

You're gonna be rubbing elbows. It's only going to be like three hundred dish people, you know, so like it's not a ton of people. It's a small kind of tight knit community. You're gonna get a chance to meet everybody, including myself, and you're going to see a bunch of Reactnat or a bunch of Infinite Red and React Native engineers running around with red shirts, so you can talk to any of them. So it is July. We have a workshop day on the seventeenth and then the eighteenth

and nineteenth of July our talk days. So we have a bunch of exciting stuff kind of planned for that. So go to chain reactcomp dot com and uh and and get your get your tickets there. I'd love to see you all at chain React in Portland, Oregon. And then yeah, we we do a lot of other content. I have a YouTube channel, although I haven't put out a video for a little while. I do need to do that, but it's called Jamin's Code Quests, and I go kind of splunk through stuff, I explain stuff. I

you know, it's it's kind of fun. And you can also go to my Twitch stream just my first and last name, Jamon Holgren on Twitch. I do stream from time to time, and I have a podcast, REAC Native Radio, which is all about react Native. We just crossed our three hundredth episode, which is fun and I think you folks are when how many episodes have you done? Now? It's it's up there as well.

again touch upon the companies that produce the show. So Top and Depths produces all the podcasts in this top end Umbrella React round Up being one of them, but we also have shows about Angular, Ruby, on Rails.

This is un void dot com. And what's interesting is that instead of paying per hour, you only pay per tasks, and you pay only after your tests are delivered and uproot.

So it's not just they delivered and you pay. You actually do quality control before you commit to paying to them, so it's on their best interest to deliver you quality work best So that means that all the biggest pain points that company have companies usually have with software outsourcing are just gone when you work with them, So do check out if you're interested in that. That's it for me. Thank you for sticking up to the end. We're almost

at one hour. You could have changed this episode, the episode of this podcast for one episode of House of the Dragon, which, by the way, I encourage you to do eventually because it's really good this new season.