Jed Bartausky:

Welcome back to another episode of the React Native Radio podcast, episode 340 React Native Web versus React strict dom part two with Evan Bacon and James Ide.

Jamon Holmgren:

Robin, I have 140 of my wife's relatives coming into town between today and I guess tomorrow.

Robin Heinze:

Just your wife's relatives?

Jamon Holmgren:

Yes.

Robin Heinze:

This isn't even your relatives?

Jamon Holmgren:

No, no. Just my wife's.

Robin Heinze:

That's a big family.

Jamon Holmgren:

We have a reunion happening, so

Robin Heinze:

Where are you all even fitting?

Jamon Holmgren:

There's like this camp kind of north of here that apparently there's plenty of cabins enough to, we pretty much rented the whole thing.

Robin Heinze:

Take over the whole place. Yeah.

Jamon Holmgren:

So yeah,

Robin Heinze:

Pretty sure if you got my family reunion together, we'd fit in one house.

Jamon Holmgren:

Technically mine did too.

Robin Heinze:

Okay. That house had how many bedrooms?

Jamon Holmgren:

I don't know. It was

Robin Heinze:

Like 20,

Jamon Holmgren:

I think it was owned by a Mormon family or something, and then the Airbnbed it a lake house. That was pretty good. That was in January,

Robin Heinze:

But you could say you fit your whole family in one house.

Jamon Holmgren:

Yeah, and there were 43 of us, so that was my mom and dad, my eight siblings.

Robin Heinze:

That was just your immediate family and their kids.

Jamon Holmgren:

My mom and dad, my eight siblings and their families, but this one, my wife is the youngest, so I'm the second oldest of nine kids and my wife is the youngest of 12 kids, and so yeah,

Robin Heinze:

It's bigger. It just gets exponentially bigger.

Jamon Holmgren:

That's right. Yeah. Luckily I get along with pretty much everybody on her side. They're pretty cool

Robin Heinze:

People. Well, and if you don't get along with someone, you don't even have to see each other.

Jamon Holmgren:

140 people, I'm sure. I won't say hi to many of them. Not on purpose. It's just you get lost in the crowd. Should be fun, but it'll be busy around here, but that's not why we're here. We're here to do a podcast. We have a couple of guests, of course. I'm Jamon, she's Robin, and we have a returning guest, of course. Evan Bacon. Welcome back.

Evan Bacon:

Hey Evan. Yeah. Thanks so much for having me again

Jamon Holmgren:

From Expo. How big are your family reunions?

Evan Bacon:

Yeah, in the middle of seven kids.

Jamon Holmgren:

Okay. Oh, that's decent

Evan Bacon:

In size.

Jamon Holmgren:

Yeah. Yeah. And then James, have you ever been on the podcast? I think

James Ide:

My first time. Thanks for having me.

Robin Heinze:

This is your first time. Welcome on.

Jamon Holmgren:

Yeah. James eDay. That's how you say your last name, right?

James Ide:

That's correct.

Jamon Holmgren:

Okay, awesome. He smiled. That's not a very common thing to get it right. James, how about you? How are your family reunions?

James Ide:

Depends on which side of my family. My mom was one of

Jamon Holmgren:

Nine.

Robin Heinze:

Okay, okay.

Jamon Holmgren:

Yeah,

Robin Heinze:

So you know about big families too.

Jamon Holmgren:

Yeah. You do. Yeah, yeah. Alright, cool. Well, Evan of course works at Expo Legendary within the React native community builds all kinds of cool stuff. We'll talk about some of it here and then James, who's a little more behind the scenes I think, but just as important in my opinion. Co-founder of Expo does all kinds of cool stuff, actually not as public as maybe Evan and I are about the cool stuff he's working on, but he's always doing cool stuff. Before we get into our topic, let's talk really quickly about our sponsor, which is Infinite Red. Infinite Red is a Premier React native consultancy located fully remote. In the US we have about 30 people we're actually hiring, I don't know actually by the time this comes out we may be done. We'll see. So we may be a little bigger, I don't know, 32, 33, we'll see.

We don't hire very often and we do React native consulting, of course, it's all experts, it's all senior plus usually staff level engineers across the board. Average is just under 15 years of professional experience and of course reach out to us if you have any React native project. Doesn't matter what it is. If it says React native, we're interested in talking to you, go to Infinite Red slash Radio. Alright, let's talk about our topic. On the last episode we talked with Nicholas Gallagher from Meta about React Native Web versus React strict dom and it was a good discussion. We kind of went over the differences between them. Of course, he was the creator of React Native Web and React strict dom and we just talked about how Meta uses the two tools and how they see them going forward in the React native ecosystem. And from talking to Nicholas, it was kind of apparent that he saw React Native Web as being react native on web and then react strict on as being React JS web on mobile. It's kind of like two different directions there. I'm going to start with James and then I'll go to Evan who I'm pretty sure has an opinion about this. Is that how you think about this as well, the differences between those two libraries?

James Ide:

Yeah, that's absolutely one way to look at it. React native for web was a very good way to take the APIs that are designed for Android and iOS and then allow you to take that code and run it on web while still rendering real dom components under the hood. The native UI framework of the web is the dom. The native language of the browser is JavaScript, so it's still React native, it's just that the native code is JavaScript and the native UI is the DOM With React strict dom, one of the nice things is that we can reduce that level of abstraction by using things like dibs and spans more directly and the question is then do we want to bring divs and spans as an abstraction to Android and iOS? And of course the classic answer in software engineering is it depends. It depends.

Robin Heinze:

Yeah,

James Ide:

That's true.

Jamon Holmgren:

That is a good point. Evan, anything to add to that?

Evan Bacon:

Yeah, when I first found React native, what was really magical about it coming from just an objective C Swift background building apps was that a few things. You didn't need auto layout constraints. You could just do flex one and it would fill the space. You could just do a flat list instead of setting up a UI table delegate view, this whole nonsense rigamarole and then the animated API was fantastic, so it was just my ability to express a front end very quickly. I could just move at a rate that I was never able to with the underlying native platform and then it just was native views, so it was all these kind of help reviews that helped you build more beautiful UIs faster and React Native Web was very similar where it came at a time when they were building the Twitter website or the Twitter light PWA where there was all these little styling bugs across different browsers, especially phone mobile browsers and React Native web had similar, you could add aspect ratio and you could do all these different styling techniques which would normalize, like Nick Gallagher wrote normalized CSS, which was very popular. Didn't know how many developers nowadays know about that, but

Jamon Holmgren:

I didn't know that.

Evan Bacon:

Yeah,

Jamon Holmgren:

Yeah, he didn't mention it

Evan Bacon:

And so Ran of Webb was very much like that, but the component level, so really the name of the game with a lot of React native has been enable really beautiful UI development and I think over time some of that, basically everything else is caught up at this point. So all these Safari bugs have been mostly ironed out and then on iOS and Android, they have their own versions of React basically built in and so now there's a question of are there still styling issues and how can we improve those? So I think a lot of the need for React native web and that abstraction has basically been upstreamed at this point.

Robin Heinze:

Gotcha. I mean Expo uses React native web, right?

Evan Bacon:

Yeah, well, I mean Expo uses React native and then Expo runs on web, so if you have any React native code, it's nice that it doesn't just fall over when you run it on web, but Expo router for example, it is a React framework first,

So you can just use any web code in it and then you can add React native on top of it and then if you run it on web, then it keeps working. So if you had div support and CSS support in iOS and Android, then you could just theoretically not use React native, you would just use those built-in primitives. And there's really less about the div, it's more about the missing styles. In div, there's no display block in yoga, so you can add a div, but then it's display Flex and it feels like kind of a rug pull.

Robin Heinze:

What about React strict dom? Is there anything in the XPO ecosystem that's using React strict dom currently?

Evan Bacon:

I think there's been a few people have used it. The dialect part seems like the trickier part to work with just it's got some bundler magic behind the scenes, but I think a member of the expo community added the post CSS plugin, so the expo CLI has post CSS support. For those who are not familiar with post CSS is kind of like a babble for CSS, so given a CSS file can transform it into a different kind of file and so we can use that for style X, make it a little bit easier and then that helps consume the styles. But overall, I think the real missing piece here is just more native styles and upstream yoga in an upstream React native.

Jamon Holmgren:

Yeah, yoga of course being the layout system for React native.

Evan Bacon:

Yeah, we actually were very lucky. The engineer who added flex gap to yoga has joined the expo team. He's working on linear gradient and React native and radio gradient and background position and back. He joined and he added PRS open for six or seven new style properties just like upstream. So that helps mitigate a lot of the pain. It is like call a view, call it whatever you want. It's really like if those style properties are missing, ultimately that is what fundamentally defines if a front end framework is good, can you build beautiful UIs with it?

Jamon Holmgren:

Yeah, it's funny because before I really was, well, I mean I was probably an early teenager and I was trying to figure out Cub basic and stuff and I knew one programmer, one guy that could code and I asked him what makes a programming language better? How do you think about this stuff? And he boiled it down to basically what functions are available to you. That's how he looked at it. How many things can you do that are built into the language or maybe of course the third party ecosystem because the fewer functions there are, at least in his opinion, the more work you had to do to make progress. Of course, he was speaking to 13-year-old me, so he was really dumbing it down for me, but I've always kind of thought about that over the years. There is some truth to that. Maybe that's a little simplistic, but in some ways it's kind of true of this as well because what attributes are available, what styling properties, like not having block layout maybe doesn't cause too much of an issue for us when we're just building mobile apps, but if you want to match to existing web code, then that can be a little bit problematic.

I am curious actually, James, how you think about this stuff because a lot of times I've really appreciated how you think really high level about it. How do you think about when you would choose React native web versus React strict dom in any particular case?

James Ide:

Yeah, over time I would say things would move in a direction of React strict dom, and part of this is because the web actually has quite a good implementation of its UI framework that the dom and so to be able to use that in a very direct way is quite nice. One way to think about this is if you were able to write your UI using Disney spans where appropriate, then that would make the web implementation just work really, really well. It would be kind of zero abstraction. And so this is going to sound maybe a little bit counterintuitive, but one of the ways to improve the quality of the web version of a project would be to actually invest energy into the Android and iOS implementations to bring diviv and SPAN implementations to those platforms so that you could write all of your code using divs and spans where again, where appropriate, I say where appropriate because there are some places like the navigation system, a lot of the stuff that Expert router does where you do not want to write your routing system in divs and spans sure on the web.

Everything does eventually need to get represented in terms of those components and literally not divs and spans, but whatever the web provides. But on Android and iOS, we want to use the navigators that are native to those platforms so that you get 100% of the native experience with all the little built-in Zinex animations and hidden gestures holding down on the back button to bring up the history. All of that native behavior is something that end users want. So that's why I say might not use business fans everywhere. But going back to the original question about where would you use React to strict DOM or React strict DOM versus React native Web, I would say you would typically want to use strict dom more moving forward, but I do think that React Native web is a good thing that exists today. One difference between the two is that React Native Web has more production usage, it's just more mature, and so there is a lot of value in using something that again, people can actually use today. Going back to the earlier topic of what can you do with a programming language? Well, you can do things a lot more things with React native web today

Jamon Holmgren:

I demand the marquee tag, that's what I want and blink in Blink. Right.

Evan Bacon:

Well, I have good news for both of you. Oh, great. The headlining features of Expo SDK 67.

Robin Heinze:

Yes,

Jamon Holmgren:

Of course. I think it's

Robin Heinze:

Literally headlining. It is a marquee after all.

Jamon Holmgren:

Yeah, I mean Nicholas also made it pretty clear that React strict DOM is Meta's choice going forward as well.

Robin Heinze:

I mean that's where investing,

Jamon Holmgren:

Yeah, and there's still places obviously for your Act Native web and whatnot.

Robin Heinze:

I want to get at what our audience is mainly wondering, and they're all app developers and they're facing starting a project and they're PM or their client or whoever wants a equivalent first class web experience and a first class native experience for both, but they want to use React native and they want to be able to use the same developers for all of their platforms. Is it possible, if you're trying to have a first class experience on both, what do you use, what should you reach for? Can you get a first class native experience using React strict dom? Can you get a first class web experience using React native for web? Do you need to use a combination of both? What would you do in that position? What would you reach for?

Evan Bacon:

I mean, right now the two stickiest pieces are expo router by a long shot for web native parody, and then I'm seeing a lot of just tailwind usage for a website. You need media queries, you need all these styles, and then on native, they just need to fall back. So we are investing a little bit more in CSS parsing generally. The way some of the Tailwind stuff works is that you just have a CSS parser that works in React native, and then you just have Tailwind compiled down to CSS Tailwind, whichever CSS Library compiles down to CSS works. But we're finding Tailwind just works really well because you can declare the media queries. So those two pieces alleviate a lot of the cross-platform maybe pain, and then after that it's just the question of which components you use. Honestly, for instance, right now you could do MPX create expo dash E with dash html, and that will pull down a project. It uses XPO HTM L Elements, which is a slightly older version of strict dom, but essentially the same principle. And you could just type lowercase diviv, span P, whatever, and it will convert them to views and images and texts behind the scenes. Interesting. But again, it does kind of break expectations because it is flex by default instead of display blocks. So if you're building a website that's very text heavy, like a markdown document or something, that's where you start to see display block, inline block and even CSS grid really, you start to feel the pain, so you add those. Then the semantics of which component tag you use, I think matter very little,

Jamon Holmgren:

But then you could just switch to expo dom components for a document heavy component and just ride with a web view. Right.

Evan Bacon:

Yeah, actually DOM components have really grown on me. I really, really love expo dom components. Yeah, saying James is saying earlier, which I really agree with, is that the browser has written a very, very competitively performant version of diviv. It's going to be harder to write a better version of Diviv anywhere, right? The browsers really nailed the performance of the dom, and so if you wanted to create a one-to-one div component, it's very likely not going to be more performant than the version in the browser. So that's where you start to fall somewhere in the middle with something like strict dom where it's like it's more performant just by nature of having fewer features and having more limitations. And then if you want one-to-one exact diviv, that's where you reach for an expo dom component. You just literally use a div, you mark it with used dom, that's probably going to be the most performant version of a diviv that is the most spec compliant that you can access. So really we want to just give people that variety.

Jamon Holmgren:

Yeah, I mean, I see React Native is kind of just orchestrating all these different renderers that you can use. And that's actually a good point. I actually wrote down as a question, at what point are you just re-implementing a browser and there's this feel like web views are slow browser, the DOM is slow. There's all those types of kind of feelings and maybe in comparison to the very, very stripped down version of views that we have in React Native. That's true, but just because it's written in native, I mean a browser is written in native, A lot of 'em are written in c plus plus, right? They're fast and there's a lot of work that's gone into optimizing them, just like you said Evan. So yeah, that makes sense.

Evan Bacon:

Yeah, it's just the gestures, scrolling and animations that are like the webc. At no point in the development of expo, we've been like, oh, we want to copy the gesture system from the browser or the scrolling system of the browser.

Jamon Holmgren:

It wasn't designed for that.

Evan Bacon:

Right? Even if you had a strict on Diviv overflow auto, that is not something we are interested in adding. Maybe the meta is interested in it, but you can just immediately tell when you scroll something on iOS and it's not that Correct scroll, bounce and momentum.

Jamon Holmgren:

Yeah. Yeah. I'm really glad to hear that expos aligned with meta on this because obviously I think it's fair to say that those two companies are probably the most important in the React native ecosystem. Obviously there's others that do a lot of really great work as well, but we need to make sure that the two biggest players there are aligned. I'm sure there's small differences in priorities and whatnot that do pop up from time to time, but I think Meta is clearly investing as much as they can in probably more on the Rack strict Dom side, but we probably do still need to maintain React native web. Is that something that Expo is going to be helping with or how's that going to work going forward?

Evan Bacon:

Well, potentially if we introduce just for example, expo image, which has an alternative to React native image that has web support in it, we maintain that for forever. Yeah, it depends on some of these components. I think I could see us moving to a place where maybe use a diviv, maybe use a View something, and that will probably be mostly stable React Native's view component is very stable, and all the changes that we're seeing land in it recently are just making it have more parody with React Native Web. Native web is very far ahead. It has background image, it has all the CSS key frame animations and stuff. And so Nihon is adding a bunch of these Cs S properties to React native upstream really bringing it to parody with Web, and then Software Mansion with Reanimated V four is adding CSS, keyframe animation, some of these transitions. So yeah, I think it'll mostly be fairly stable for a long time. I don't think React native web has really changed much at all, and

Jamon Holmgren:

Yeah, that's fair.

Robin Heinze:

No, I mean Nicholas basically said he doesn't, he approves PRS if people submit 'em, but he's not really doing any feature development on it anymore.

James Ide:

Part of the reason for the stability is that the UI components that are exported from React Native haven't changed a lot. For instance, things like the new architecture have been the source of more changes, but that doesn't really affect web,

Robin Heinze:

Right? The actual API of components and stuff has been stable,

James Ide:

Fairly stable, and then of course the DON and browser APIs are also one of the most stable APIs in the world. Maybe not the most, but close to it. So for that reason, I would say React native web, it's somewhat evergreen to that nature. And then over time, I'd expect there to be a migration path that is very incremental

Jamon Holmgren:

For

James Ide:

A project that is targeting Web to be using React Native Web, and then also to introduce more of the dos and spans and PS in a React strict on manner until finally you have a hundred percent of your project moved over.

Robin Heinze:

So you can see it being an incremental adoption. And

James Ide:

I think that is the best path if possible. Every developer wants to do an incremental migration and for a mature app, it's like I can see a lot of companies just saying they can't afford to break user facing functionality just for a technical change. Yeah,

Robin Heinze:

You're going to have a hard time selling that to a product owner.

Jamon Holmgren:

Yeah. And stakeholders. Yeah. James, how important is the web as a target platform to expo? Because you all have been mobile first, you've been focused on making sure it's a great iOS and Android experience as much as possible, more than anything. But how do you think about Web just in terms of your company?

James Ide:

Yes, it's important for us and we repeatedly, continuously have discussions around how to bring Web up to or beyond the level of Android and iOS. And like I alluded to before, sometimes that means investing actually on the Android and IS side to bring web APIs to those platforms in order to improve the quality of web. Again, if we can let developers write where appropriate code using web-like APIs and provide good implementations of those on Android and iOS, then that makes the web implementation just super straightforward in several ways. And we've been doing this say with the Fetch API that's now on Android and iOS. It has streaming support, which is great for all this LM stuff that's been coming out in the past couple of years. And then now that allows people to just kind of write fetch and it works across Android, iOS, but on web of course it uses just the browsers builtin implementation.

So we want to do more of that. And then in terms of why we care about Web, I would say it's for a couple reasons. One is that the web is the most successful application platform. It's just where the most users are, and it's simple to look at the, say even MPM downloads of React Dom versus React Native and React DOM is 10 x higher. So it's pretty clear that this is a meaningful audience to focus on. And at Expo, our view is it's not web versus native. We believe in web and native, and there are a lot of users, maybe even everyone listening to this call can relate to this, where you might have the mobile app installed and you want to share a link with a friend and that friend doesn't have the app installed. You're way more likely to share the link with them if you know that they're going to be able to view that Instagram post or that Reddit post or whatever it might be in their mobile browser or even on the desktop. And then over time, if they repeatedly like Instagram or Red or whatnot, then they can go get the mobile app.

Robin Heinze:

Someone needs to tell that to TikTok because

Jamon Holmgren:

They just jam you towards every time

Robin Heinze:

I get sent to TikTok link, they're like, no, you can't view this.

Jamon Holmgren:

You need the app.

Robin Heinze:

Literally, you try to press play and it takes you to the app store. And I'm like, I don't want the app. It just, even a of my friend sent me.

James Ide:

Sometimes you're just like, I'm happy to stay in the web browser, or you have the app on your phone, but you want continue your session on your desktop computer on your laptop and view the browser there. So Amazon could be a good example where you'd want to have both a web version and a mobile version, a native mobile version, and be able to continue your session, especially on Apple platforms with, I believe Handoff is the name of the feature. It's really great when developers can deploy to all platforms everywhere.

Jamon Holmgren:

So my follow up question here is are you going to use Expo Web for, or do you already use Expo Web for your expo dashboard, your web dashboard?

James Ide:

Yeah, the web dashboard for historical reasons, it's through with Next js, and that's generally been working fine. So we just

Robin Heinze:

There, it's not broken.

James Ide:

We do dog food expo web for our blog and have actually embedded that into our main website. So you can see our website is hybrid between next GS and Expo Web, and we also are using Expo web for some not yet launched web properties as

Jamon Holmgren:

Well. Interesting little teaser

James Ide:

There.

Jamon Holmgren:

That's pretty cool. Yeah,

Evan Bacon:

All new projects are being built with Expo across all platforms.

Robin Heinze:

Yeah, I

Jamon Holmgren:

Love that. I love that. And then when you're using your own product, then that's when you are like, oh, this isn't good enough. We need to do this, we need to do that. I've had a little taste of that recently. I started building a React native macOS, like a rewrite of React Toron in React Native Macs. It's Electron now. And I wanted to follow the Ignite principles and the Ignite patterns and stuff, and a lot of 'em are pretty good and well test and everything, but there's a few that I'm like, okay, yeah, we need to come back to this and take another look at it. I don't know, it's not feeling right to me, that sort of thing. So yeah, dogfooding, that's important stuff. Awesome. Well, I know we have more to talk about with this stuff, but we're running out of time here, so I really appreciate you both coming on and talking about this. Of course, you can find both of them online, social media, GitHub, different places like that, and yeah, hope to have you on again soon at some point to maybe talk about some of the new stuff you're working on.

Evan Bacon:

Yeah. Excellent. Thanks so much for having us.

Jamon Holmgren:

Great. Robin, do you have a mom joke to take us out of the episode?

Robin Heinze:

Yeah, I do. So this one is, this one's from Darren from our Jokes channel in Slack. I had to drop my dog at the vet because he ate a bunch of Scrabble tiles. There's been no word yet.

Jamon Holmgren:

Okay, we'll see you all

Jamon Holmgren:

Next time. Bye.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editors, Jed Bartausky and Tyler Williams, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.