Speaker 1: Hey, welcome to React Round Up, the podcast where we
Speaker 1: keep you updated on.
Speaker 2: All things React related.
Speaker 1: This show is sponsored by Raygun and produced by Top
Speaker 1: and Doves and onboard. Top and Doves is very great
Speaker 1: Top and Doves, so get top and pay and recognition.
Speaker 1: We're working on interesting problems and making meaningful community contributions.
Speaker 1: And Onvoid, which promotes which provides remote design and software
Speaker 1: development services on a task basis, so clients only pay
Speaker 1: when tests are delivered and approved. In today's episode, we
Speaker 1: have a very special guest so that we can talk
Speaker 1: about React Native versus capacity just as an even larger
Speaker 1: interro for those of you that may not know what
Speaker 1: the pastor is is yet another technology that allows you
Speaker 1: to transform your web code so that it can run
Speaker 1: all mobile as well, similar to how React Native does
Speaker 1: it like in terms of the final product, but they.
Speaker 2: Do it in a very different ways.
Speaker 1: So today we're going to talk about those two technologies,
Speaker 1: what are the differences between them, and when to use
Speaker 1: each depending on your context and the context of your
Speaker 1: team and your company. My name is Lucas Spaganinia. I'm
Speaker 1: your host in a podcast, and joining me in today's
Speaker 1: episode is also the host Peter Osa. I agree, and
Speaker 1: our very special guests coming back for another for another episode.
Speaker 1: Jamn Homegram.
Speaker 3: Yeah, nice to be on again. Really nice to see
Speaker 3: you guys again.
Speaker 2: It's great having you.
Speaker 1: For those of you that may have that may have
Speaker 1: not listened to the previous episode where Jamen was, I
Speaker 1: think it was like four or five episodes ago, something
Speaker 1: like that, but it was an episode completely focused.
Speaker 2: On React Native.
Speaker 1: So if you want to deeper into that, just go
Speaker 1: to the history of the show and then you go
Speaker 1: back a few episodes and you will see it. This
Speaker 1: as a recap. Jamen is the CEO and co founder
Speaker 1: of Infinite Red, which is a company specialized in building
Speaker 1: either from scratch or just taking a project in the
Speaker 1: middle and completing it in React Native. So this is
Speaker 1: what he does for a living. He's the perfect person
Speaker 1: to tell us the difference between those two technologies.
Speaker 3: That is a great pitch. I should hire you to
Speaker 3: do all of our promos. That's perfect.
Speaker 1: We can do that happily. Accept Yeah, all right, so Jamin,
Speaker 1: let's get into it. Do you mind giving the audience
Speaker 1: a quick pitch if you feel as necessary, because I
Speaker 1: think I kind of introduced the goal of Capacitor, But
Speaker 1: if you feel there's anything else necessary before we get
Speaker 1: into the differences between them.
Speaker 3: Now, yeah, I think you know, most of the time,
Speaker 3: Capacitor is connected to Ionic, and a lot of people
Speaker 3: are probably familiar with Ionic, which is I would say
Speaker 3: like more of a full featured framework, and Capacitor is
Speaker 3: more of like a cross platform native run time a lot,
Speaker 3: you know, and we'll talk about the similarities and differences
Speaker 3: between that and React Native and it leans on the
Speaker 3: web technologies, but just like Reacnative, it has a lot
Speaker 3: of the same you know, kind of goals and features
Speaker 3: and whatnot. Now, I do want to tell the audience
Speaker 3: I've been doing React Native for eight and a half years.
Speaker 3: I the last Capacitor or Ionic project, I should say
Speaker 3: that I've done was about that long ago. So what
Speaker 3: I know about Ionic and Capacitor has been from a
Speaker 3: distance or spinning up a little like play apps. I
Speaker 3: haven't built apps in Capacitor that are that are like
Speaker 3: really significant, so I always have to put that caveat
Speaker 3: out there like that this is, you know, like this
Speaker 3: is something that I want to make sure that I
Speaker 3: that I do a good job of comparing the two
Speaker 3: and and don't just lean on my own like experience
Speaker 3: and and and even my own what my company specializes
Speaker 3: in and that sort of thing. With that said, in
Speaker 3: order to like prep for this episode, I actually reached
Speaker 3: out to my friend Jessica Sachs, who used to work
Speaker 3: for Ionic, and I went and I actually chatted with
Speaker 3: her and I said, hey, look, I really want to
Speaker 3: make sure I've got this right, and and we talked
Speaker 3: for a while about what, you know, what Ionic and
Speaker 3: Capacitor really like, what the state of the art is
Speaker 3: in twenty twenty four. And I think, I, uh, you know,
Speaker 3: I I think I'm I think I'm well well armed
Speaker 3: for this. I think I can probably do a pretty
Speaker 3: decent job where she won't be like cringing hopefully if
Speaker 3: she listens to this episode.
Speaker 2: Awesome, So you basically did a podcast to prepare for
Speaker 2: the podcast.
Speaker 3: I should have This is just a Twitter DM discussion,
Speaker 3: but I should I should have done I should have
Speaker 3: brought her on my my podcast reacting of radio. That
Speaker 3: would have been really fun. Yeah, we could make that happen.
Speaker 1: Definitely, definitely Okay, Awesome, We're we're also going to try
Speaker 1: to bring her here.
Speaker 2: I think it's that's that could be really interesting.
Speaker 3: Yeah. Absolutely, If she was, I'll just volunteer her. She
Speaker 3: has no knowledge of this, but.
Speaker 2: Thank you Jessica for me up for this.
Speaker 3: Wow. Yeah yeah.
Speaker 1: So one interesting thing to clarify through the audience is that,
Speaker 1: as far as I'm aware of and I'm not, i
Speaker 1: am no Ionic expert myself as well. But maybe you
Speaker 1: can clarify this to me since you talked to someone that.
Speaker 2: Words at Ionic.
Speaker 1: For the first time that I saw Ionic, it was
Speaker 1: like three years ago or so, and.
Speaker 2: I thought it was a framework, but then.
Speaker 1: It was presented to me in an online course as
Speaker 1: actually a UY library that compiled to the native components,
Speaker 1: and then that was my understanding at the time. And
Speaker 1: then recently I was trying to look up Ionic and
Speaker 1: I realized that currently Ionic itself is the company. So
Speaker 1: they named the company as Ionic, and then they have Capacitor,
Speaker 1: which is one of the products of the company called Ionic,
Speaker 1: and they have the UY library of components, which is
Speaker 1: the Ionic framework. So is that correct? Like Ionic? Just
Speaker 1: Ionic is the company. Ionic Framework are the UI components
Speaker 1: that also come along with Capacitor because they depend on capasitor,
Speaker 1: And then Capacitor itself is just the the build pool
Speaker 1: that can transform your web code into mobile applications, but
Speaker 1: it doesn't come with the pre done UI components that
Speaker 1: translate to the native forms.
Speaker 2: Is that it.
Speaker 3: I think you did a good job, and I'm going
Speaker 3: to start bumping up against the because this stuff it
Speaker 3: can be kind of fuzzy, you know, like because I
Speaker 3: mean even Ionic, Like if you go to ionicframework dot com,
Speaker 3: they call it Ionic, like they say introduction to Ionic.
Speaker 3: Ionic is an open source UI toolkit, you know. So
Speaker 3: but I think you're right because ultimately I think that
Speaker 3: the framework itself is Ionic. There is a company Ionic,
Speaker 3: which is you know, of course maintaining it and kind
Speaker 3: of like building a business around it. And then Capacitor
Speaker 3: is really the technology that they created in order to
Speaker 3: have per performant like as performance and capable as possible
Speaker 3: bridge over to the native side. So yeah, I think
Speaker 3: you did a good job.
Speaker 1: Though. Cool And they have another interesting product called app flow,
Speaker 1: and they also have live updates, which I thought was
Speaker 1: really interesting. And I don't know if we're even going
Speaker 1: to get into it, because I think perhaps we would
Speaker 1: need a deeper understanding of the rest of the ecosystem
Speaker 1: to even talk about that, but I was really curious
Speaker 1: to understand if app flow and their live deployment picture
Speaker 1: only work with Capacitor or Ionic, or if it actually
Speaker 1: worked or React Native as well, because from their website,
Speaker 1: I see that they have logos of other pools. So
Speaker 1: if you go to their website for app flow, which
Speaker 1: is a product of the Ionic company, then it has
Speaker 1: a logo for a capacitor are you, but also for
Speaker 1: React Native and Cordora, So I thought that was interesting.
Speaker 3: Yeah, Ionic interestingly, and I've chatted with some of the
Speaker 3: other Ionic folks as well, and they really have have
Speaker 3: started to branch out, and like in some ways, they're
Speaker 3: sort of like the Expo of capacitor, you know, like
Speaker 3: they have all the other tools on top of capacitor.
Speaker 3: That's kind of how you it's not a perfect technology,
Speaker 3: but like it's it's sort of like building on top
Speaker 3: of this technology. But unlike Expo, which is double down
Speaker 3: and React Native, they are they seem to be adopting
Speaker 3: other technologies and providing solutions across the board, so they
Speaker 3: seem to have a wider I guess umbrella across you know,
Speaker 3: React Native and and their technologies and and whatnot. They
Speaker 3: do provide things like, yeah, the c CV service and
Speaker 3: and and more. So, Yeah, it's it's an interesting company
Speaker 3: for sure, And I've liked all the people that I've
Speaker 3: talked to there. They're good engineers. They seem to understand,
Speaker 3: you know, what us developers go through and whatnot.
Speaker 2: Cool.
Speaker 1: Have you yourself ever used some of those tools that
Speaker 1: allow you to have real time updates.
Speaker 3: On the React Native side. I have not, you know,
Speaker 3: not so much on the Ionic side, but for sure
Speaker 3: on the React Native side, we've used them all, like
Speaker 3: on multiple projects, including rolling our own. We've had to
Speaker 3: build our own because sometimes clients will come to us
Speaker 3: and say, I want to React Native app. I want
Speaker 3: over the air updates, but nope, I can't use Expo
Speaker 3: and nope, I can't use app Center, and nope, I
Speaker 3: can't use you know, any of the other options that
Speaker 3: are out there. So we build our own, and we
Speaker 3: build something in house and then use that. It's not
Speaker 3: actually that difficult, I would say, especially when we've done
Speaker 3: it a few times. But of course, building all the
Speaker 3: features out that you might expect from an over there
Speaker 3: update perspective, that's where it, you know, where like you
Speaker 3: get into it's like a deep rabbit hole there.
Speaker 1: And I know that this is a bit off topic,
Speaker 1: but in the last episode we were discussing that when
Speaker 1: you're dealing with native apps, you have to support the
Speaker 1: users that are in old versions or you need to
Speaker 1: like literally just block them and say, hey, if you
Speaker 1: want to use the app, you need to update. And
Speaker 1: that's completely different from what we have on the web,
Speaker 1: where we just assume that all users are in the
Speaker 1: latest versions, but those over the air updates they fix
Speaker 1: this problem, right, But the complexity comes from the bureaucracy
Speaker 1: of getting approval from the play Store and the App
Speaker 1: store from Apple because from what I understand, the thing
Speaker 1: that they are trying to prevent is companies pushing code
Speaker 1: that didn't went through their official review process, right, So
Speaker 1: how do you make this all out?
Speaker 3: Yeah? Absolutely, well, I mean this is a this is
Speaker 3: a very deep subject. Of course, there's there's a lot
Speaker 3: of different factors here. One might ask, what what right
Speaker 3: do Google and Apple have to you know, review this
Speaker 3: in the first place, right, Like, and that's big, it's
Speaker 3: a big discussion. They're they're kind of gatekeeping this and
Speaker 3: can be very arbitrary and and they've even gotten in
Speaker 3: trouble for some of their practices around this. The other
Speaker 3: thing you could say is, well, okay, so this isn't
Speaker 3: native code. This is just like JavaScript that's getting uploaded.
Speaker 3: So it's really no different than in a browser loading
Speaker 3: a new website, right, like you can just jump to
Speaker 3: a new website. But Apple and Google seem to have
Speaker 3: different rules around browsers versus other apps, like they seem
Speaker 3: to really kind of differentiate between the two, and certainly
Speaker 3: they have a financial a vested financial interest in disallowing
Speaker 3: things that act like other app stores and Epic has
Speaker 3: like had these massive battles with Apple around we should
Speaker 3: be able to provide our own app store the inside
Speaker 3: of the iOS eco system, and so you just kind
Speaker 3: of keep going down this rabbit hole for now where
Speaker 3: we are is they allow it as long as you
Speaker 3: don't change the significantly change the like core functionality of
Speaker 3: the app, or introduce things that you know, like you know,
Speaker 3: get around the app store and rules. And the problem
Speaker 3: is that there's really not a lot preventing people from
Speaker 3: abusing this. So when it gets abused, not if, but
Speaker 3: when it gets abused in that kind of high profile
Speaker 3: way where someone ships over the air and update that
Speaker 3: like brings in something that Apple would consider egregious. Then
Speaker 3: there's probably gonna be a battle around this and they're
Speaker 3: gonna start saying you can't do this. So it's something
Speaker 3: that I'm keeping a very close eye on. It's like
Speaker 3: Evan Bacon from Expo correctly says that over there updates
Speaker 3: is one of reac Native's killer features. It's also, by
Speaker 3: the way, Ionic capacitors killer feature too, because you can
Speaker 3: do the same thing there. But we're always a little
Speaker 3: bit leery of like like over selling that just because
Speaker 3: Apple could come in and put the hammer down. If
Speaker 3: that happens, they're going to have a battle on their
Speaker 3: hand though, and they're already fighting some battles you know,
Speaker 3: in the EU and other places including the US. And
Speaker 3: so this is a whole podcast episode topic. I could
Speaker 3: go on forever about it, but it is. There's a
Speaker 3: lot more to this story, but it basically is like, yes,
Speaker 3: it's awesome, we use it. We try not to do
Speaker 3: it in such a way that like if Apple came in,
Speaker 3: they would get really mad at us, just because they
Speaker 3: unfortunately are the gatekeepers here and you know, don't don't
Speaker 3: rely on it forever, Like that could be problematic. Now
Speaker 3: there is obviously the other way for submitting updates, and
Speaker 3: we can always send in a new new build and then,
Speaker 3: you know, two weeks later, get a rejection that gives
Speaker 3: you no information about why it's rejected, and then have
Speaker 3: to guess on how to fix it. I'm not bitter
Speaker 3: at all. I'm sure you can't tell.
Speaker 1: No, not at all. I can I can see that
Speaker 1: I'm bitter for you, dude.
Speaker 3: I've been dealing with this for oh man, it's almost
Speaker 3: twenty twelve years now.
Speaker 1: So yeah, Well, although this was somewhat off topic, it's
Speaker 1: still on topic, right because.
Speaker 2: Since we're discussing differences between.
Speaker 1: Capacitor and React Native, one of the things that we
Speaker 1: could discuss is this over their functionality, and it seems
Speaker 1: that it's not unique feature of either of both. Right,
Speaker 1: you can have this with React Native. You could have
Speaker 1: this with Capasitor as well.
Speaker 3: I'm sorry, can you ask that question again?
Speaker 1: Yeah, the over the air updates, they could be done
Speaker 1: either with React Native or Capacitor. So this is one
Speaker 1: of the things that is not really a difference between them.
Speaker 1: Maybe the way that it's done can be different, but
Speaker 1: they both supported.
Speaker 3: Yeah, yeah, exactly, and this is the benefit of both
Speaker 3: of them using a JavaScript bundle because you can just
Speaker 3: ship a new JavaScript bundle. Now today most React native
Speaker 3: apps actually ship Hermes bytecode bundle, which is I mean,
Speaker 3: you've probably heard of like web assembly and web assembly has.
Speaker 3: You know, you can like basically ship what would be
Speaker 3: sort of JavaScript, but it's in a bite byte code format. Similar.
Speaker 3: I guess if In from the Hermes team was listening
Speaker 3: to this, he would cringe because he knows all the
Speaker 3: reasons that that's wrong. But that's basically how I think
Speaker 3: about it is that it's in those terms, but it's
Speaker 3: still kind of JavaScript under the hood, you know, it
Speaker 3: still has the same kind of characteristics and whatnot. Under
Speaker 3: the hood, it's just been compiled from JavaScript. So it's
Speaker 3: a bundle, it's a file. It's a single file. Like
Speaker 3: in most cases and the vast majority cases, it's a
Speaker 3: one file. You literally just put it up on an endpoint,
Speaker 3: and your app downloads it just like it would download
Speaker 3: any file, replaces it or puts it in a certain spot,
Speaker 3: and then starts using that bundle reloads, you know, like
Speaker 3: it starts using that bundle instead. So that's essentially how
Speaker 3: it works.
Speaker 1: Gotcha, Okay, So let's go into some of the differences
Speaker 1: between it. What would you say, especially after your talk
Speaker 1: with someone from the Ionic company, what would you say
Speaker 1: are the most interesting differences between you React Native and
Speaker 1: Capacitor or just the entire ironic framework.
Speaker 3: What I like to do in these situations is really
Speaker 3: kind of help the audience understand at what level we
Speaker 3: are comparing them, because if we're simply comparing them from
Speaker 3: a technical standpoint, like what you can achieve standpoint, then
Speaker 3: you might go one direction. But I like to look
Speaker 3: at technologies holistically. There's a lot more to a technology
Speaker 3: than just what can you achieve with what ease with
Speaker 3: what developer experience. Certainly, those are a big part of it,
Speaker 3: and you know that's something I've searched for my entire careers,
Speaker 3: better solutions for doing those things. However, these apps are
Speaker 3: usually for businesses, and these businesses have constraints, and these
Speaker 3: constraints matter. So when you look at things like Native
Speaker 3: versus React Native, or PWA's versus Mobile at All, these
Speaker 3: all have these questions wrapped up in them around the
Speaker 3: business parts of it, and Ionic and React Native both
Speaker 3: approach this problem very pragmatically. They come at it like, hey, look,
Speaker 3: we all want good experiences, but we also understand that
Speaker 3: we have constraints and we want to be able to
Speaker 3: ship quickly with technologies that we all know and that
Speaker 3: we can share across multiple teams. We want to enable
Speaker 3: the biggest cohort of developers, which is web to build
Speaker 3: and deploy mobile apps. So they both really approach that
Speaker 3: from that standpoint. Now where they differ is where they
Speaker 3: make these trade offs and what they're willing to trade off.
Speaker 3: So I would see it in some ways as there's
Speaker 3: different levels of of abstraction here. So obviously you can
Speaker 3: build a native app. You can even go lower and
Speaker 3: than a native app like like you know, you're you're
Speaker 3: you're just like writing like super low level like c
Speaker 3: or whatever. But you can you can write what you
Speaker 3: know Swift in Cotland, you can build in the native SDKs,
Speaker 3: and that gives you some benefits of like being able
Speaker 3: to customize and really fine tune at that level your apps.
Speaker 3: But the business problem is that your web developers are
Speaker 3: a little bit intimidated by like hey, like like hey,
Speaker 3: build me, build me a mobile app. In both Swift
Speaker 3: and Cotland by the way. You know, this isn't like
Speaker 3: a React developer who's just done JavaScript, you know, and Typeescript,
Speaker 3: Like they're going to have to learn a lot of
Speaker 3: stuff to do that. Additionally, if you want to be like, Okay,
Speaker 3: I'm going to build out my team of iOS developers
Speaker 3: and I'm going to build up my team of Android developers.
Speaker 3: Now now you have three teams, three different subcultures will emerge.
Speaker 3: I've seen it every time, like they're working together all
Speaker 3: the time. And anytime that you have teams, I mean
Speaker 3: my own team, like you know, we're thirty some people.
Speaker 3: We now only do React Native, but at the time
Speaker 3: when we started, we did Elixir, we did React Web,
Speaker 3: React Native, we did a few other things too, And
Speaker 3: those subcultures would emerge. They would hang out together, they
Speaker 3: would talk together, they would like share knowledge together, but
Speaker 3: they wouldn't do it across their teams. So now you
Speaker 3: have three different I remember talking to Square Space for example,
Speaker 3: and Square Space had like in their office they had
Speaker 3: I think in New York, they had like a pod
Speaker 3: for their Android developers. They had a pod for their
Speaker 3: iOS developers, they had a pod, huge pod for their
Speaker 3: Web developers. When they went to React Native, and this
Speaker 3: would have been the same if they went to Capacitor.
Speaker 3: They were able to re architect their literally their office,
Speaker 3: like like remodel their office, to combine those into a
Speaker 3: single team that was divided up in different ways, and
Speaker 3: they could all talk together, they can all help each other,
Speaker 3: et cetera. And so when you're talking about the trade
Speaker 3: offs that we're talking that we're making here, this is
Speaker 3: like one of the key things about Ionic. And I'm
Speaker 3: gonna say, whenever I say Ionic and Capacitor, just assume
Speaker 3: I'm talking about the whole thing. I don't want to
Speaker 3: have to I'll just say Capacitor. I'll just I'll say capastor,
Speaker 3: even though that's like one chunk of it. All right,
Speaker 3: So anytime you're talking about Capacitor and reac natives, that's
Speaker 3: the major benefit. You bring in all the knowledge of
Speaker 3: your web developers, all the a lot of the tooling,
Speaker 3: not all of it, but you bring in a lot
Speaker 3: of the tooling. You bring You can share code, like
Speaker 3: if you have a validation function you know, something like that,
Speaker 3: or even just a library that you use you can
Speaker 3: use across the board. You can share types if you
Speaker 3: use Typescript, like you can say, Okay, you know I
Speaker 3: want to use I'm consuming this API and it has
Speaker 3: this type. Okay, well, our iOS app, our Android app,
Speaker 3: and our web app all share the same types, and
Speaker 3: you can kind of go from there. And every time
Speaker 3: I see this happening at any company, it's incredibly striking
Speaker 3: how compelling that story is. It's the business case of it,
Speaker 3: and it's the organization, it's the human element that really
Speaker 3: really changes there. And then there's a speed element as well,
Speaker 3: because you're building two to three sometimes plus platforms at
Speaker 3: a time rather than rebuilding it over and over. And
Speaker 3: I've done the rebuilding over and over. I've done the web,
Speaker 3: and then now we have to build an iOS app.
Speaker 3: And now turns out people actually want androids. Okay, we
Speaker 3: want Android, let's put it. And you're having to build
Speaker 3: it over and over and over and solve the same
Speaker 3: problems over and over and over, and it just feels
Speaker 3: like a waste of time, Like why are we doing
Speaker 3: this over and over? Like build it once or at
Speaker 3: most like build it twice, and and you'd have web
Speaker 3: and then mobile. Right, So Ionic really want to lean
Speaker 3: wants to lean toward let's build it once, like let's
Speaker 3: use all web technologies and whatnot, so they will like
Speaker 3: the technology itself. For those who don't know capacitors using
Speaker 3: a web view like they have, they have native bindings,
Speaker 3: but it's not for the UI, Like the native bindings
Speaker 3: are at the S or they're at the API level.
Speaker 3: So you want to like get your location, or you
Speaker 3: want to get you want to access the accelerometer, or
Speaker 3: you want to like have a little you know, like
Speaker 3: have the phone vibrate or whatever hapic feedback, then they'll
Speaker 3: provide native bindings for those. But then the UI itself
Speaker 3: is just rendered in a browser, so it's all the
Speaker 3: normal technologies that you're used to, like like HTMLCSS, JavaScript,
Speaker 3: all in the browser and you can use all of
Speaker 3: your web knowledge within that. React Native is not going
Speaker 3: to do that. React Native uses just JavaScript and when
Speaker 3: you it has all the same like native bindings for
Speaker 3: all the device features, but the UI layer is actually
Speaker 3: building native views. And so that's the main difference is
Speaker 3: on capacity. You're going to have a WebView running with
Speaker 3: a browser and then on the React Native side you're
Speaker 3: going to be running native views. But there's trade offs
Speaker 3: there because a browser, even though it's heavier, it's sort
Speaker 3: of like like Electron for example, brings with it all
Speaker 3: these benefits of using the powerful web technologies that we've developed,
Speaker 3: where React native has to re implement some of that
Speaker 3: stuff and and like like make for a similar feel there.
Speaker 3: So it's really at the business level, and then you
Speaker 3: have to start thinking about the tech level and the
Speaker 3: trade offs there and how far are because there are
Speaker 3: there are limits to how far you can go with
Speaker 3: a web view, like like at some point that like
Speaker 3: high fidelity buttery is smooth kind of feel that you
Speaker 3: want from an app. You may hit it, You're you're
Speaker 3: gonna you're gonna probably hit a ceiling with with ironic,
Speaker 3: but that ceiling is a little higher than you think,
Speaker 3: and it also is uh you know, it's it's not
Speaker 3: every app needs like the buttery smooth feel because maybe
Speaker 3: you're you're just really tapping between screens and stuff like that.
Speaker 2: Yep, Okay, So basically.
Speaker 1: What you're saying is well, at least one portion of
Speaker 1: what you're saying because there were many points touched.
Speaker 3: But kind of was a rabbit trail there.
Speaker 1: Sorry, ye, But one important thing that I think we
Speaker 1: could highlight and correct me if I'm wrong. Most developers
Speaker 1: think that the ceiling that they're going to hit with
Speaker 1: going with either Capacitor or React Native is lower than
Speaker 1: it actually is. So if you're afraid of trying to
Speaker 1: build it once and ship it everywhere because you think
Speaker 1: that for some reason your application has a particular feature
Speaker 1: that is just not going to work with trying to
Speaker 1: use those hybrid technologies in most scenarios, you're actually wrong.
Speaker 1: In most scenarios, you can actually build it hybrid and
Speaker 1: you're not going to regret it, And the chances that
Speaker 1: you're going to have a feature that is simply not
Speaker 1: supported unless you're native are extremely small or perhaps even
Speaker 1: an existent, because I think you can still mix and
Speaker 1: match right native code with hybrid.
Speaker 3: Yeah, that's right, and you're exactly right. The ceiling is
Speaker 3: a lot higher, especially in my opinion, with React Native,
Speaker 3: and we can go into that, but because I would
Speaker 3: say that, for example, the the browser does limit some
Speaker 3: things with Capacitor because you can't bring in like a
Speaker 3: native component and put it into a browser, where with
Speaker 3: React Native you literally can sprinkle every other component, could
Speaker 3: be a custom native component that you wrote in Swift
Speaker 3: or Cottlin and just drop it right into the middle
Speaker 3: of your Reactnative app and it works like you can
Speaker 3: do that. So that's uh, we're starting to get into
Speaker 3: some of the trade offs here. Ionic has a lot
Speaker 3: of benefits and I can go into some of those,
Speaker 3: including things like it's much easier to set up than
Speaker 3: React Native. I mean, that's just every Reacnative will admit that.
Speaker 3: It's true, it's like so much easier. But this is
Speaker 3: one place where you're going to hit the ceiling sooner
Speaker 3: with capacitor. It's you're going to hit that level because
Speaker 3: you can't then drop into native when you need to.
Speaker 3: Now capacity devs will say how often do you actually
Speaker 3: need to do that? Like not very often, And it
Speaker 3: is true, it's not very often. But you have that
Speaker 3: extra tool to reach for with React Native, which you
Speaker 3: would not. And that's why I think I've been very
Speaker 3: happy with Reacnative. I feel like it really hits that
Speaker 3: kind of sweet spot between all the convenience and whatnot
Speaker 3: with the potential for customization.
Speaker 1: Gotcha, Okay, that's very interesting, So we react native specifically.
Speaker 1: Let's say that I'm super hyped about the WWDC that
Speaker 1: just happened, and I want to use the latest API
Speaker 1: that Apple just released. I want to build for vision
Speaker 1: os to like the second that Apple releases it, is
Speaker 1: it already available to me? Or do I need to
Speaker 1: wait for the latest version of React Native or whatever.
Speaker 3: So the essentially that it would be available to you
Speaker 3: with some caveats. There are some situations where where you
Speaker 3: might need React native to It depends. Okay, here's the
Speaker 3: biggest question. It's really it really comes down to do
Speaker 3: you want React native to support it or do you
Speaker 3: just want the ability to put it in your app?
Speaker 3: Because as always, you can drop in a Native and
Speaker 3: you can add anything you want that is supported in Native,
Speaker 3: like anything Bleeding Edge, Brand New whatever. React Native itself
Speaker 3: might not have a binding for that, and that's fine,
Speaker 3: like you could. You know a lot of times when
Speaker 3: something comes out, people want to play with it and
Speaker 3: you'll find a third party library that pops out in
Speaker 3: the next week or two. Like it happens all the time.
Speaker 3: But I have said this for many, many, many years,
Speaker 3: and I'll keep saying it until I'm blue in the face.
Speaker 3: Here's the deal. React Native developers need to not be
Speaker 3: scared to write native components. They need to not be
Speaker 3: scared of that. It's really important. I've thought about even
Speaker 3: making my own course. Like, take this course and you
Speaker 3: will no longer be scared to write your own native
Speaker 3: component because if some new feature comes out WWDC or
Speaker 3: whatever and you want to take advantage of it in
Speaker 3: your app and you don't want to wait on anybody
Speaker 3: else to do this, just build it yourself. It's not
Speaker 3: that difficult, it really is not. And so yeah, there's
Speaker 3: there's really there's really no leg time. No more than really,
Speaker 3: I mean like native apps all the time will leg
Speaker 3: on adding new features just because of engineering time. Like
Speaker 3: you got to implement it, you got to add it
Speaker 3: in right, No more than that, Like, and if you
Speaker 3: really really want to do it, you just build a
Speaker 3: native and integrated into your app. Now, if it's something
Speaker 3: that React Native should be taken care or taking advantage of,
Speaker 3: then you may wait a little bit for the core
Speaker 3: team to kind of catch up with her. You can obviously,
Speaker 3: it is open source, so you can contribute to React
Speaker 3: Native and kind of help that process. But those are
Speaker 3: kind of few and far between. It's rare that something
Speaker 3: actually affects the core of sure all.
Speaker 1: Right, I thinks as a last one, at least for me,
Speaker 1: in terms of things that pop up. If you go
Speaker 1: to Ionic's website, they have an article written by their
Speaker 1: CEO and co founder, Max Lynch, and they explain the
Speaker 1: difference between Ionic react which is the React version of
Speaker 1: the Ionic UI components, and React Native. And one of
Speaker 1: the things that they say there, which I think it's
Speaker 1: really interesting, is that they say that there's a difference
Speaker 1: between how Ionic and React Native approach cross platform support.
Speaker 1: They say that React Native takes up learn once, write anywhere,
Speaker 1: and Ionic takes up right once, run anywhere. And basically
Speaker 1: what they're saying is that the differences with React native.
Speaker 1: You learn Reactnative and then you use it to create
Speaker 1: screens specifically for Android and specifically for iOS. And in
Speaker 1: contrast with Ionic, you don't think about either iOS or Android.
Speaker 1: You just write it once and you trust that they're
Speaker 1: going to package and that single build is going to
Speaker 1: work for Android and iOS. Which sounds cool, but then
Speaker 1: it brings so many other questions from my mind, like
Speaker 1: this example that we were just talking about WWDC, like
Speaker 1: Vision os two only exists in the Apple ecosystem, Like
Speaker 1: it's never going to exist in the Android ecosystem, So
Speaker 1: how do you build it once if you have something
Speaker 1: that it's only going to exist in a particular ecosystem.
Speaker 3: So I'll be honest, this tagline annoys me a little bit.
Speaker 3: The learn once, run anywhere. To me, I want to
Speaker 3: say this without being like too negative, but to me,
Speaker 3: it feels a lot like developers trying to lower expectations
Speaker 3: so they don't get criticism. That's what it feels like.
Speaker 3: Learn once, run anywhere. Oh we never said you could
Speaker 3: write it once and run anywhere, so don't criticize us
Speaker 3: if it doesn't work that way. I think that tagline
Speaker 3: is just wrong. I think it's just wrong based on
Speaker 3: literally like almost one hundred apps that we've built over
Speaker 3: the last nine years, like big ones, like tons of them.
Speaker 3: And we started out with React Native version zero point eleven.
Speaker 3: It's now up to zero seventy four or seventy five
Speaker 3: depend when this comes out. And here's the deal. Like
Speaker 3: the very first apps that we started with two parallel
Speaker 3: projects just to try it out make sure it worked,
Speaker 3: we got over eighty percent code reuse in that very
Speaker 3: first project. It was like close to ninety percent code
Speaker 3: reuse between iOS and Android. Over the intervening years, we
Speaker 3: have regularly hit one hundred percent code reuse or ninety
Speaker 3: nine percent code reuse like once in a great while,
Speaker 3: we'll have a little if platform OS is Android, do
Speaker 3: this otherwise, you know. Or we might do the extension
Speaker 3: thing where it's like index dot Android dot tsx, index
Speaker 3: dot iOS dot tsx and it'll render that. But it's
Speaker 3: the vast majority of the code that we write is
Speaker 3: write once, run anywhere, vast majority, And I think it's
Speaker 3: done more harm than good. It's to me, it's been literally,
Speaker 3: I think that slogan is just a kind of lower
Speaker 3: expectation is all it is. And so then people will
Speaker 3: then take it very seriously and say, oh, well, we
Speaker 3: have to write every screen twice anyway, so why would
Speaker 3: we use react native. It's not true. You just don't
Speaker 3: like in real life, you know. Ninety eight percent, I'll
Speaker 3: say ninety eight percent. I'll be the developer lowering expectations here.
Speaker 3: Ninety eight percent of your code is going to be
Speaker 3: the same. It's gonna be the code that you're going
Speaker 3: to use one component for both. And usually when you're
Speaker 3: making a differentiation, it's either because of platform differences as
Speaker 3: far as what they support, which you would have to
Speaker 3: do anyway in Ionic, or or it's differences that you
Speaker 3: want to like, you want, like Android users expect this
Speaker 3: to be different, you know, so you're kind of like
Speaker 3: catering to your user base. iOS and users expect it
Speaker 3: to be this way and Android the other way. So
Speaker 3: in that case you should write something different there. But yeah,
Speaker 3: this is a little bit of a rant. I'm sorry,
Speaker 3: but like the whole learn once write everywhere to me
Speaker 3: is a it's it's not a good slogan. Expo XPO talks.
Speaker 3: You know, Expo says, create universal native apps with React
Speaker 3: that run on iOS or Android iOS in the web,
Speaker 3: so they I think have a better tagline. Uh. And
Speaker 3: to me, Expo kind of gets this a little bit
Speaker 3: better than you know, like meta engineers are brilliant, they're
Speaker 3: incredible engineers, not always the greatest marketers. That's not what
Speaker 3: they're you know, there for. Uh and so sometimes these things,
Speaker 3: you know, like, it's a very engineer type slogan, not
Speaker 3: one that I likely gotcha.
Speaker 1: Okay, Well, in any case, Jessica from Ionic can now
Speaker 1: even have more reasons to come here and defend.
Speaker 2: Yeah, yeah, no, that makes sense.
Speaker 1: Okay, man, I'm sure there are thousands of other things.
Speaker 1: Do you, Peter, please do you have any any questions?
Speaker 4: Okay, yeah, I think one just one question on the
Speaker 4: pay fourmance.
Speaker 1: Right.
Speaker 4: So, first of all, capacitor is like your web view, right,
Speaker 4: also reactative, this is like native right. So I think
Speaker 4: most of the time we go to reddits and many forms,
Speaker 4: people usually does talk about performance, which which one actually
Speaker 4: performs better on which one and so on and so forth.
Speaker 4: So kind of give like you may be a breakdown
Speaker 4: of which one you feel those beast or do? Actually
Speaker 4: I have my answer, Well, I just want to get yours,
Speaker 4: because yeah, yeah, that'll be cruse.
Speaker 3: It's a great question. And like I said, uh, I
Speaker 3: think up to a certain point, you get the same
Speaker 3: performance or a similar performance, because usually there's a lower
Speaker 3: threshold where performance anything above that doesn't really impact the user.
Speaker 3: Like you'll you have sixty frames per second, maybe you
Speaker 3: have one hundred and twenty frames per second. If you
Speaker 3: can render four thousand frames per second, does the user
Speaker 3: notice that? No, because the screen literally only updates one
Speaker 3: hundred and twenty times per second. It's not going to
Speaker 3: update four thousand times per second. Even if you could,
Speaker 3: you know, a human could perceive that. So within that,
Speaker 3: like if you're in the games industry and you're working
Speaker 3: within like frame rate you know windows, you you kind
Speaker 3: of understand around like like what matters and what doesn't.
Speaker 3: If you're doing some work and then you know, you
Speaker 3: you make the frame window like you're in that frame window.
Speaker 3: You're good, Like you're you're fine. Now, there may be
Speaker 3: some other things that matter there, like battery life and stuff,
Speaker 3: and certainly we think about those things, but it's not
Speaker 3: the perceived performance of the app, like that's not that's
Speaker 3: not called that's not affected there. So that's number one,
Speaker 3: like what matters. It's a there's a lower bound of
Speaker 3: like it's got to be at least there, like we
Speaker 3: got to hit the frame, you know, we can't be
Speaker 3: skipping frames. And then the other part of it would
Speaker 3: be like what if you start getting into really heavy
Speaker 3: screens where it is not possible to like start hitting
Speaker 3: those those frame rates, or there's other things that are
Speaker 3: wrong with it. And there's just one really important rule
Speaker 3: before we get into the technical limitations, which is you
Speaker 3: can write poor performing apps in any language anywhere. I
Speaker 3: don't care if you're writing C plus plus, I don't
Speaker 3: care if you're writing handcrafted assembly. You can write it
Speaker 3: in such a way that it's it's poorly. It performs poorly,
Speaker 3: and because of that, there's a variety of ways to
Speaker 3: approach this. But you have like compilers that will that
Speaker 3: will and like like JavaScript engines that will take the
Speaker 3: the code that you write and try to optimize. They'll
Speaker 3: do things like inlining functions, they'll do things like you know,
Speaker 3: memoizing things and like shortcuts and whatnot, and those can
Speaker 3: very much help. But where capacitor hits the limit is
Speaker 3: the limit of the browser that is in the system,
Speaker 3: so the WebView, the web engine, so that brings with it. It's
Speaker 3: a certain amount of overhead itself. And then especially on
Speaker 3: iOS it's usually not as advanced. Google seems to take
Speaker 3: their web view a little more seriously and the engine
Speaker 3: a little more seriously, so the Android side seems to
Speaker 3: be a little faster. However, there's still limits there because
Speaker 3: you know, it's a web browser. So the performance of
Speaker 3: Ionic is going to be a cap. At some point
Speaker 3: you're going to hit that or capacity. You're going to
Speaker 3: hit that cap, you're gonna hit that ceiling. React Native
Speaker 3: also has a ceiling because of and this is kind
Speaker 3: of like influx right now, because the new architecture. But
Speaker 3: there is a ceiling because of the the JavaScript bridge.
Speaker 3: But there's a number of ways to get around that.
Speaker 3: So one is that you can run more things on
Speaker 3: the native side. So animations, for example, you craft the animation,
Speaker 3: you send the information over the bridge, and then the
Speaker 3: native side does all of the animating like you don't
Speaker 3: even it doesn't even hit the jobscript side, So you
Speaker 3: just have like everything running in the native side. And
Speaker 3: then obviously if you need to, I always tell my
Speaker 3: developers like, don't be afraid to drop in native if
Speaker 3: you need to. But vast majority of the time, just
Speaker 3: the universal truth is someone has to care. If someone
Speaker 3: cares about performance, you can get so much further before
Speaker 3: you hit the limits of the technology itself. So someone
Speaker 3: caring and spending the time will go super super far.
Speaker 3: And then yeah, the React native apps are native apps
Speaker 3: because you can drop in a native any time you want,
Speaker 3: and you can build anything you need to. So there
Speaker 3: should never be an excuse for poor performance in a
Speaker 3: React native app. There might be an excuse for poor
Speaker 3: performance in a capacitor app, And that's okay because the
Speaker 3: way that that Jess kind of described it to me
Speaker 3: when we talked about this is that she really recommends
Speaker 3: Ionic and capacitor apps for more like document focused apps,
Speaker 3: like apps that are more like around content like that.
Speaker 3: If you're talking about app focused apps like like you
Speaker 3: know that need like really smooth animations and scrolling, and
Speaker 3: you know think something like I don't know, dual Lingo
Speaker 3: or Instagram or something like that, then it makes sense
Speaker 3: to maybe go with something you know, something else and
Speaker 3: Reacnative of course would be a prime thing there. But
Speaker 3: performance really isn't an excuse with reacnative. There should never
Speaker 3: be something that you can't achieve with REAC native in
Speaker 3: as far as performance. And I will say just a
Speaker 3: shout out for my own company, Infinite Read, if you
Speaker 3: have trouble hitting that performance, then come talk to us,
Speaker 3: because there's no reason why you can't get there, and
Speaker 3: certainly if you have us built alongside you all the way,
Speaker 3: we'll teach you how to how to build perform apps
Speaker 3: like that. That's part of what we do.
Speaker 4: Is also, Yeah, I think I think I'm actually very
Speaker 4: quite satisfied with that. Yeah, because the web view as
Speaker 4: space was really like it was actually a point actually
Speaker 4: noticed because that was something that I felt like, Yeah,
Speaker 4: if Capasito is going to have like a boat name,
Speaker 4: that would be where it would be right, was the
Speaker 4: limit of the web few and so yeah, I think
Speaker 4: you kind of went through that very well.
Speaker 2: Yeah, I think, yeah, that's quite great.
Speaker 1: All right yamen, I'm gonna throw in a catch all
Speaker 1: question just before we wrap things up. Do you think
Speaker 1: there's anything that you would like to mention that perhaps
Speaker 1: we haven't asked and you think would be relevant for
Speaker 1: this subject.
Speaker 3: Yeah. I think when when you're thinking about the subject
Speaker 3: of capacitor versus React Native, one of the biggest questions
Speaker 3: you should be asking yourself is your team makeup and
Speaker 3: the business needs. And I mentioned this before. Now, if
Speaker 3: you if you're using something like Angular and you would
Speaker 3: love to continue to use Angular, you know, and just
Speaker 3: kind of keep that rolling throughout your your organization, then
Speaker 3: you can consider something like Ionic and capacitor, because that
Speaker 3: would be you know, that would be a possibility there.
Speaker 3: If you are using React. I know that there's Ionic React,
Speaker 3: but I think you should strongly consider React native just
Speaker 3: because of the flexibility. There are some other like like
Speaker 3: view Native and svelt Native and stuff like that try
Speaker 3: to build on top of React Native However, they're not
Speaker 3: the greatest supported, you know, generally speaking, So I would
Speaker 3: say if you if you're insisting on using something other
Speaker 3: than React, then yeah, consider consider Ironic and Capacitor. If
Speaker 3: you're using React, use well, really Expo. You should be
Speaker 3: really looking at Expo and uh, it's gonna be hard
Speaker 3: to beat the the combination there. I think it really
Speaker 3: makes good, good trade offs. I'm I'm still a huge
Speaker 3: fan of React Native after all these years, which normally
Speaker 3: I move on to another technology after five years, and
Speaker 3: this is like almost double that now, So yeah, very much.
Speaker 3: I think that's that's a kind I think where and
Speaker 3: you know, I can help you make that decision if
Speaker 3: you if you're a company, you know, talk to me.
Speaker 3: I'm more than happy to chat about it. And uh,
Speaker 3: but I always try to I always try to have
Speaker 3: like you know, I I don't want to be unfair
Speaker 3: to these other technologies. There's reasons, there's it's as like
Speaker 3: every that you know, the joke is like it depends right,
Speaker 3: like there's a it's a it's a trade off discussion
Speaker 3: and whatnot. And for my particular values and what I
Speaker 3: want to hit, you know, business wise as well as
Speaker 3: technology and developer experience wise, I really think React native
Speaker 3: makes sense, but obviously there are totally valid reasons to
Speaker 3: use something like capastor.
Speaker 1: Okay makes sense talking about this, let's do some promos
Speaker 1: and talk a little bit more about what it is
Speaker 1: that you do, because that was mentioned in the beginning.
Speaker 1: But just seri either besides being the CTO and co
Speaker 1: founder of a company.
Speaker 2: That is specialized in React native.
Speaker 1: So as Jimin was just saying, any company that is
Speaker 1: even considering exploring this route should definitely check out Infinite
Speaker 1: Red's website and contact them. Besides that, you also do
Speaker 1: lots of content, right, and some of them even produced
Speaker 1: and sponsored by Infinite Red. I know there's a conference
Speaker 1: that's going to happen. I think in perhaps you can
Speaker 1: talk a bit more about that.
Speaker 3: Yeah, that's right, So Chain React. This will be the
Speaker 3: fifth edition of Chain React. It is purely react native conference.
Speaker 3: So if you go there, you're gonna be surrounded by
Speaker 3: React native developers or people who are interested in React native.
Speaker 3: All of the talks at single track two day conference
Speaker 3: in Portland, Oregon, it's all React Native. It's the people
Speaker 3: you know from Meta, from Microsoft, from Amazon, all these
Speaker 3: big companies that are using React Native will be there.
Speaker 3: You're gonna be rubbing elbows. It's only going to be
Speaker 3: like three hundred dish people, you know, so like it's
Speaker 3: not a ton of people. It's a small kind of
Speaker 3: tight knit community. You're gonna get a chance to meet everybody,
Speaker 3: including myself, and you're going to see a bunch of
Speaker 3: Reactnat or a bunch of Infinite Red and React Native
Speaker 3: engineers running around with red shirts, so you can talk
Speaker 3: to any of them. So it is July. We have
Speaker 3: a workshop day on the seventeenth and then the eighteenth
Speaker 3: and nineteenth of July our talk days. So we have
Speaker 3: a bunch of exciting stuff kind of planned for that.
Speaker 3: So go to chain reactcomp dot com and uh and
Speaker 3: and get your get your tickets there. I'd love to
Speaker 3: see you all at chain React in Portland, Oregon. And
Speaker 3: then yeah, we we do a lot of other content.
Speaker 3: I have a YouTube channel, although I haven't put out
Speaker 3: a video for a little while. I do need to
Speaker 3: do that, but it's called Jamin's Code Quests, and I
Speaker 3: go kind of splunk through stuff, I explain stuff. I
Speaker 3: you know, it's it's kind of fun. And you can
Speaker 3: also go to my Twitch stream just my first and
Speaker 3: last name, Jamon Holgren on Twitch. I do stream from
Speaker 3: time to time, and I have a podcast, REAC Native Radio,
Speaker 3: which is all about react Native. We just crossed our
Speaker 3: three hundredth episode, which is fun and I think you
Speaker 3: folks are when how many episodes have you done? Now?
Speaker 3: It's it's up there as well.
Speaker 2: It's pretty close. It's I think two hundred and seventy
Speaker 2: or something.
Speaker 3: Yeah, yeah, you done a ton. So there's uh, there's
Speaker 3: a lot of uh content, reacnative content there and we
Speaker 3: interview lots of people, uh lots of different topics. It's
Speaker 3: pretty much the biggest Reacnative podcast. And uh we have
Speaker 3: a Reacnative newsletter so Reacnative Newsletter dot com. I don't
Speaker 3: know I could keep going. I don't want to. I
Speaker 3: don't want to bore everybody. You can go to infinite
Speaker 3: dot read and click through our website. You'll see at
Speaker 3: all it's there.
Speaker 1: Awesome, Okay, and Peter, how about you would you like
Speaker 1: to bring up anything? Yeah?
Speaker 4: Most a little more do I just will I think
Speaker 4: we sent little with a lot complear. I think I
Speaker 4: will just expliment a testing so I just clear right,
Speaker 4: So yeah, I think that's your's.
Speaker 2: You gotta check it out. Adopted the link and the
Speaker 2: chat you okay, awesome.
Speaker 1: I also sent some of the lengths in the comments section.
Speaker 1: For those of you that are watching us from YouTube
Speaker 1: or any of the other livestream platforms, there should be
Speaker 1: something in the comment section first for Chain React cof.
Speaker 1: If you're not, then it's just Chain React cof dot com.
Speaker 1: There's also the website for Infinite Red. It's literally just
Speaker 1: infinite dot red, so I mean, you can't really go
Speaker 1: wrong with that. And I'm also gonna send the article
Speaker 1: that Peter just mentioned. On my end, I'm just gonna
Speaker 1: again touch upon the companies that produce the show. So
Speaker 1: Top and Depths produces all the podcasts in this top
Speaker 1: end Umbrella React round Up being one of them, but
Speaker 1: we also have shows about Angular, Ruby, on Rails.
Speaker 2: Cic D.
Speaker 1: Anyways, there's a bunch of stuff, so do check out
Speaker 1: Top and Dews. You can go to the website and
Speaker 1: see all the shows available. And Onvoid, which provides remote
Speaker 1: design and software development services. What if you're looking for
Speaker 1: React native, then don't consider avoid just go straight to
Speaker 1: infinite Red. But for other inquiries, do checkout onvoid dot com.
Speaker 1: This is un void dot com. And what's interesting is
Speaker 1: that instead of paying per hour, you only pay per tasks,
Speaker 1: and you pay only after your tests are delivered and uproot.
Speaker 1: So it's not just they delivered and you pay. You
Speaker 1: actually do quality control before you commit to paying to them,
Speaker 1: so it's on their best interest to deliver you quality
Speaker 1: work best So that means that all the biggest pain
Speaker 1: points that company have companies usually have with software outsourcing
Speaker 1: are just gone when you work with them, So do
Speaker 1: check out if you're interested in that. That's it for me.
Speaker 1: Thank you for sticking up to the end. We're almost
Speaker 1: at one hour. You could have changed this episode, the
Speaker 1: episode of this podcast for one episode of House of
Speaker 1: the Dragon, which, by the way, I encourage you to
Speaker 1: do eventually because it's really good this new season.
Speaker 2: So yeah, thank you for sticking with us for so
Speaker 1: Long, and I will see you in the next one.