Todd Werth:

Welcome back to React Native Radio Podcast, brought to you by the Island Resort Alliance. Join us and relax. Episode 339. React Native Web versus React strict Dom Part one.

Jamon Holmgren:

Robin, are you using cursor these days or are you still rocking BS code?

Robin Heinze:

Well,

Robin Heinze:

I am technically using Cursor. I have it, but I haven't been coding on projects for six months, which is kind of sad, so I haven't gotten back into my world. I haven't really honed a really good cursor setup and flow. I just haven't gotten to use it much. But when I do code, I have been using Cursor. Yeah,

Jamon Holmgren:

I was early to copilot. I loved it, but then I tried Cursor and Bs. Code is still installed on this machine.

Robin Heinze:

I open say I can't, can't install it. That just feels mean. It

Jamon Holmgren:

Feels wrong.

Robin Heinze:

It feels wrong vs. Code has been so good to me for so

Jamon Holmgren:

Long, but I know some listeners are like, well, you all aren't moved to Claude Code yet. You're supposed to be. That's the new thing.

Robin Heinze:

Oh, is that the new thing's

Jamon Holmgren:

Cursor?

Robin Heinze:

Cursor out

Jamon Holmgren:

Way better. And

Robin Heinze:

Claude Code is in

Jamon Holmgren:

Supposedly. Yeah.

Robin Heinze:

Oh man, I can't keep up with this.

Jamon Holmgren:

I can't either.

Robin Heinze:

I feel like yesterday people were like, Hey, there's this new thing called Chat GPT. It's pretty cool.

Jamon Holmgren:

It was pretty much yesterday

Robin Heinze:

And now no one uses chat GPT anymore.

Jamon Holmgren:

No, of course not. Yeah, you've got whatever. There's so many different things. Alright, well we've got a lot to go over, so let's jump into this. I'm Jam and she's Robin. We also have a special guest host today, his first time on the podcast, which is awesome. Tyler Williams, welcome. Can you intro yourself?

Tyler Williams:

Hey. Yeah, thanks Jamon. Long time listener. First time co-host.

Robin Heinze:

You really skipped over the caller thing and now you just went straight to

Tyler Williams:

Cohost co.

Robin Heinze:

Yeah,

Tyler Williams:

Yeah, we don't do a lot of call-ins. We should though. That would be very interesting. That'd be a lot of fun. Yeah, so I recently joined Infinite Red, not so recently, October of 2024, so getting up there, but I've been listening to React Native Radio since 2021, maybe even a little before.

Robin Heinze:

It's why he applied here, honestly,

Tyler Williams:

It truly is. He

Robin Heinze:

Just wanted to work with Jamon and Robin and Mazen.

Tyler Williams:

That is a big part of it. I got into it as soon as I started working with React Native and it has really guided a lot of my work and personal development on React native coding skills and I hope also just being a good coworker. I hope I'm a good here, but I'm a staff software engineer here at Infinite Red and

Jamon Holmgren:

Spoiler

Tyler Williams:

Alert. Yes he is. Thank you.

Jamon Holmgren:

We're going to do your one-on-one review six month review here, live on the podcast.

Tyler Williams:

Yeah, I've been working in React Native since for the last four or five years. The software engineer from before that a lot of Ruby on Rails and view js. Actually a little bit of React sort of like bridged the gap there. And speaking of doing performance reviews live on air, I did work at GitLab for some time and GitLab was all about everything open so you can go to YouTube and watch my team's standups from 2018. Yeah, I think they're still there so you can go see me.

Robin Heinze:

I'm definitely doing that after we record this.

Tyler Williams:

So yeah, if people want my background they can go see me chitchatting about web components in 2018.

Robin Heinze:

That is amazing.

Jamon Holmgren:

I'm so glad our meetings are not live on YouTube. That would be

Robin Heinze:

Terrible.

Jamon Holmgren:

Yeah, that would not be, that wouldn't be good. I suppose we would behave, but yeah, no welcome. Also, Tyler has worked with me on MobX State Tree for many years as well. We co maintained it for a long time, which it was mostly Tyler doing the work. Let's be honest here. We also have a fantastic guest. I cannot wait to get into this. Our guest is Nicholas Gallagher from Meta Nicholas, can you introduce yourself as well?

Nicolas Gallagher:

Yeah, I'm Nicolas and I'm a software engineer at Meta. I work on the web platform team and I collaborate with the React team on Cross-Platform React at the moment.

Jamon Holmgren:

Yeah, awesome. And of course can't wait to get into this because you've been a pretty important part of the React native ecosystem for a long time. Having created React native for web and now working on React strict dom, which is our topic today. Before we get into it too quickly, let's really quick do this sponsor read even Red is a premier React native consultancy located fully Roma in the us. We're a team of 30 senior plus level React native developers and support staff and have been doing this for nearly a decade. If you're looking for React native expertise, hit us up Infinite Red slash Radio and don't forget to mention that you heard about us through the React Native Radio podcast. Alright, our topic today, we are going to be peppering Nicholas with questions, although hopefully we'll have

Robin Heinze:

Some, hopefully

Robin Heinze:

In a nice way to add sprinkling.

Jamon Holmgren:

We're supposed to be nice

Robin Heinze:

Sprinkles, sprinkling of questions.

Jamon Holmgren:

Yeah. Let me edit my questions here real quick. We're going to be talking about React native for web versus react to strict onm because that's sort of, it's a little bit of an alternative that's happening here and obviously we had React for web apps at first and that was 2013 comes out React native was built for mobile because it's like, all right, yeah, we can use this paradigm on mobile. And then someone who was using React Native was like, but I want to do Web. And so Nicholas just builds the web thing. Wait, hold up. Couldn't you just go backwards? Couldn't you just use React? Why happened there? How

Robin Heinze:

This, we already had a thing for Web, why?

Jamon Holmgren:

Yeah, yeah. Why did you end up going one step further and making React native for web? Where did this come from?

Nicolas Gallagher:

Well, I mean it was about 10 years ago, so keep that in mind, but we just started rebuilding the Twitter web app and React.

Jamon Holmgren:

You were working at Twitter at

Nicolas Gallagher:

This time? Yes, that's right. Sorry. I was at Twitter at the time and we were rewriting the Twitter web app and React native had recently come out and Christopher Shiau had given his CSS and JS talk that explained what the challenges they've had, what challenges matter had had with CSS at scale, which was similar to the ones we'd had at Twitter. And it essentially explained why he designed Style Sheet in React Native the way that he had. And so at Twitter we kind of wanted a version of reacts that incorporated styling and solved these problems and React Native also looked nice. It had some slightly higher level abstractions and so it was kind of a case of we wanted some form of component library, react native was one that had already been designed. I decided to kind of copy it and make a word version basically.

Robin Heinze:

There are some folks that have said that React Native is what React should have been all along.

Jamon Holmgren:

Wait, I'm right here, Robin, I've been saying this for years.

Robin Heinze:

Some people Jamon being one of those people. Is that kind of the thought process,

Tyler Williams:

Those higher level?

Robin Heinze:

Yeah, because you have these higher level abstractions that were created for React Native and then now you're just saying, okay, well the web can just be one of those platforms.

Nicolas Gallagher:

Yes, kind of. I mean we weren't using React on Native, but that became an option that we explored. Could we have a lightweight native app that would be based off what we built for the web? And yes, at the time I think I probably was thinking that not necessarily this is what React should have been, but this is where React on the web could go or should go. And over time that perspective has changed somewhat.

Jamon Holmgren:

Yeah, there's a lot of reasons maybe why it wouldn't, but we'll get into all of that. Here's a little bit of a lighter question. Why do you insist on calling it React Native four Web versus React native web, which is what everybody else calls it.

Nicolas Gallagher:

Oh, I can't remember. Is it React Native Windows or React Native four Windows? I'm not sure

Jamon Holmgren:

It's React native four Windows. That is true. That is true. Yeah, I can't, can't remember why.

Robin Heinze:

Just Habit at this point.

Jamon Holmgren:

Yeah, I suppose, yeah, that is the name though. React Native four Web,

Nicolas Gallagher:

I'm not sure. Whichever one is that what the,

Jamon Holmgren:

Is that the website? What website? Yeah, maybe it's not as big of a deal. Yeah, call it what you want.

Robin Heinze:

The idea for this episode came from a conversation that our team had, which was inspired by some discussions that have been happening on GitHub about how you've recently confirmed your recommendation for using React strict dom over React native for new projects. First, let's talk about what React strict dom is and then how it's different from React native for web and why the preference over one or the other. So I guess let's start with what React strict dom is in comparison to React native for web.

Nicolas Gallagher:

Sure. So React native for web, as you probably know is a conversion of the React native API to the web, but it's built on top of React on. And so that means that there are quite a lot of layers of abstraction on the web, including layers of abstraction that convert the standard APIs of the web into some of the non-standard APIs in React Native. So that adds to a lot of the overhead that you experience as a web developer or as a product owner who's trying to run that code on the web. You've got a runtime style sheet abstraction, you have a lot of code to convert dibs into views and add the extra props, massage the events so that the shape of the events is the same and so on. And that is more of a challenge for the web than you'd want really because there's a lot of extra time that the browser is spent doing things that you can avoid to some extent if you're using a web first framework.

And so when we were at Meta, we were looking at ways to share code across platforms and we did try using React native for web, but we were converting, we were taking existing React native code and running it on the web. And as you can imagine, there's a lot of time it's gone into the web at Meta to make those web apps as good as they can meet all the accessibility requirements, which include legal requirements now and a lot of performance monitoring as well. And so just to use React needed for web, you have to pull in a certain amount of JavaScripts before you can even write your first line of code. And so the first team that would do that would have to pay that penalty essentially because Meta has quotas essentially of how much code each surface is allowed to have, so who's the surface that's going to pay?

That initial cost was one of the questions. And then on top of that, there was just so much information loss from native to web because talking about an existing native app, well existing React native code, and that doesn't include a lot of the area props that web developers are used to using. Probably doesn't account for things like keyboard controls, responsive design in the same way. And so there was a lot of changing that would need to be done on the React native code to get it running as correctly as we wanted on the web. In contrast, a bit like the rest of the industry matter has and tons and tons of reacted web code, it's the defacto framework out there. There's nothing else on the web that we use at Meta. And so the question became like, well, can we take that web code that we've got and run that on top of React native instead?

And that's where React strict on came from because at Meta we use Style X for CSS, which was inspired by Style Sheet in React native as well as how the implementation works in React native web, which is using Atomic css. And so the stepping stone for us to take our web code and run it on native, when I looked at the situation, it seems relatively doable, at least as an aspirational or experimental first step. And that's where React strict on came from. Really it was a case of can we quickly show proof of concept of a way to run our existing web code after it's gone through some minor transformations on Native, the opposite of what React native work basically does.

Robin Heinze:

So going the other direction.

Nicolas Gallagher:

Yeah, so all of that JavaScript, the extra costs is shifted over to the native side instead, which has its pros and cons.

Jamon Holmgren:

Sure. Just a little thought that came to mind is it is interesting how much React native has influenced React how people are writing React. I don't think a lot of React developers actually know that because a lot of React developers have not done React native or haven't done Expo or really any native coating at all.

Nicolas Gallagher:

Yes. I think one of the things that I really appreciate about the React native ecosystem compared to the React web ecosystem is that in the React native world, there's only one way to do styling for the most part. And so the React native ecosystem has a lot of shared UI components and approaches to how you can share themes components as well. And on the web that's a lot more difficult because essentially when you pull a component log off the shelf, you essentially have to buy into whichever styling approach they've taken or some of 'em try to leave that door open, but obviously it's difficult to have a design system or a styled component library without making the choice there. And so one of the benefits of React Native that I've always seen is that decision is largely taken care of. And I've often wondered what would the web look like? What would react on the web look like if there was only one way to do styling? And that way people could actually share components across these component boundaries that typically exist in the web world.

Tyler Williams:

So React native for web was taking React native code, translating it back to web and now react strict on is flipping that, taking web code, giving it a new layer that can target either web and that's sort of a straight pass through to some degree or target the native platforms or perhaps even out of tree platforms eventually.

Nicolas Gallagher:

Yeah, the way that I came to understand React native was more like a JavaScript syntax for describing your UIs and React Native happens to provide tools, a lot of them like runtime to convert that into Native code and React is yes, it's defining a syntax that basically looks a lot like the web a lot react on and under the hood it's powered by React native on Native and react on web. But yes, you could be targeting something else. I think in the earlier days of React native, there were probably other more obvious experiments where people were running React native code to create canvas experiences and things like that. So I think the mental model is thinking about some kind of syntax or language to describe your ui and then the way in which React produces output on a given platform is sort of behind the scenes work that can be separate from that syntax that you're using.

Tyler Williams:

And is this the built-in semantics that I think I've seen you talk about in sort of the GitHub issues and discussions?

Nicolas Gallagher:

Yeah, so the built-in semantics are those from the web, but as I mentioned when I was saying that, which is the web platform has defined a lot of APIs for working with different types of user input working across different screen sizes, all the things that you need on web or Windows or any desktop experience. And native mobile at least on that front tends to be a subset, but even then there's technologies where you can use your Android phone on your computer. So keyboard and mouse, the ability to interact with a native app fire keyboard and mouse is not unheard of. It's just not something that React native provided out of the box when it was first released or even now to some extent.

Tyler Williams:

So when you write that components syntax from React strict dom, you'll say HTML dot some tag name that's different than React native for web, which is View text, et cetera, that a lot of our React native people will be familiar with listening to the podcast. Can you sort of say what's the difference between those two when I write those components, where are they actually coming from?

Nicolas Gallagher:

Well, when you use something from React strict dom, it's ultimately just rendering back down to a view anyway,

Robin Heinze:

But your app would look significantly different if you're using React strict dom. It wouldn't look like your regular reacting apps is that?

Nicolas Gallagher:

Well, the default layouts that we try and put into React strict on match those of the web. So there might be some differences on that front, but otherwise they're all still Unsell components. So I mean one of the challenges with React strict on is React native has a limited set of layout capabilities so it doesn't support flow layout, display block display in line, that kind of stuff. So I mean the interesting thing is the default layout of View and React native is like a flex column that's stretched and it was created that way to emulate what a div looks like by default on the web, which is a block container. And so when we emulate Display block in React strict dom, it's kind of doing the same thing. There's a bit of extra logic in there to make it so that when you set Display Flex, it goes to Flex Rowe by default as you'd expect on the web.

But otherwise we're already trying to leverage whatever capabilities are already inside of React native and reaction on itself. Like I said, it's kind of aspirational so that we created that have been removed over the last few months as those features have been built into React native proper. And I think that was really my intent with the project in the first place was to demonstrate, it's one thing to have a conversation saying, Hey, can we run web code on Native? And a lot of the time people think probably not, right? I mean things are very different. And so producing a proof of concept that shows well actually if you kind of squint a bit this we can already do it, it's just here are the gaps. Some things we polyfil and those Polyfils may be for better or worse quality wise, performance wise, there are features that we can't poly fill. Should we be adding those? Those are the kind of questions that arise instead of is it even possible? So it was really a demonstration and the fact that we've been able to use it to produce cross-platform maps even when it's still in that kind of like I said, aspirational state is I think testament to how close the two frameworks really are. And a lot of the differences that people perceive between them are really just differences in small gaps as opposed to large gaps between them.

Jamon Holmgren:

I think that convergence is sort of inevitable because we didn't necessarily, I mean if we could have waved a magic wand and had them basically act the same at the beginning, we probably would've, right? That would've been helpful because then you truly can write one code base and you can reuse a lot of your knowledge between the two platforms and things like that. So I have a couple of questions around this. One is do you feel like it will result in, okay, so I was an iOS developer prior to React native 10 years ago. I mean I did Web as well for many years, but one of the problems with a lot of the frameworks that were available at the time cross platform frameworks was they would feel like web apps, they would feel like you're running a web app. You were. And it felt like when you actually wrote and built an actual native app, people could tell the difference because of the level of Polish and just even how they worked, there were assumptions that web developers would make about how an app should work that we're entirely based around running in a browser.

And I don't think they even understood that. I don't think they understood that Native gives you different paradigms and the expectations are different from a user. So how do you combat that? Is that something that is just sort of like you need to make sure your designers understand mobile, not just mobile responsive web but also mobile native apps and that your developers do too? Or can you handle that in a way that is elegant at this level?

Nicolas Gallagher:

Yeah, good question. I think some of these questions already exist when you're just talking about running an app on Android and iOS, which is the two platforms have slightly different user experience paradigms and expectations. And so if you are really trying to share your code across platforms, you still end up with a question of if I put a button on the page, how much of that the experience of interaction with that button, at what granular level should I be in control of it as a developer versus I want React native to quote, do the right thing on a given platform. When I interact with this button on iOS, I want it to feel like an iOS button and when I interact with it on Android the same. And if you add web into the mix, that's just like another platform. And even if you're a web developer, you'll know that certain default elements behave differently on if the host platform is Mac versus Windows and you can move between those platforms if you work across both of them and you don't really stop to think about it. So there's a level of control over the user experience that is probably unnecessary because there are elements which you want to delegate to the operating system, the host environment so that it matches what a user of that platform expects. And I think some of these questions, I don't have good answers for them, but I think it's something along those lines where it's okay for there to be differences across platforms as long as those differences align with the expectations on that platform.

Jamon Holmgren:

Yeah, that makes sense. Is meta using Reacts internally and also are you seeing external adoption as well? Is it still early days for that or is that starting to happen?

Nicolas Gallagher:

Yeah, we use it internally. So obviously we've ported a decent amount of web code onto it. So it's the main apps have code that's written with React on running a production now, and then we announced the Facebook and Instagram VR apps, which were built from that shared web code. And so they share quite a lot of code with web QI code as well.

Jamon Holmgren:

I've used those because I just got a Meta Quest three, and so I've been playing around with some of these apps, which

Robin Heinze:

I think you got after talking about it on the podcast. A couple episodes ago

Jamon Holmgren:

I just had an interview and we were talking about the VR stuff and I immediately went out and bought a quest.

Nicolas Gallagher:

In those examples, I should really explain the constraints that matter, which is one of the important things that we were thinking about is you could invent a third framework, so to speak, something that isn't the JavaScript that came with React Native, we know which is sort of what was delivered when the project was first released. There's nothing particularly special about it, it's just what first came out. And then on web we've got React on and for a time we were thinking should we create a new thing in the middle? Maybe it would look kind of Swift UI or maybe kind like what Flutter is doing. There's a whole new API being designed for cross-platform for Flutter, and that's just a lot of work, a lot of work to rethink APIs, to migrate tons and tons of web code if we really wanted to do that.

And one of the early experiments that we had did involve, we introduced one component that was a new component, it was called Box. And the amount of regressions that we had on web trying to migrate divs onto this Flex box box kind of made us rethink things because it meant that it was no longer an efficiency saving to be using web as a starting point because we were having to rewrite web and deal with the regressions that was causing. So quite early on, one of the constraints became, well, what can we do to share code without having to change our web code, taking a number of regressions from 50% of all changes causing regression to zero as best as we could. And that's what React on came for is we can run a code model changes the syntax slightly to be like HTML adopted instead of div.

It cleans up a bit how stex is used with those elements and then it just keeps working as before pretty much, but now it can be run on React native. And so that might not be a use case for everyone, but we have a large pool of React developers. We know that in the open source ecosystem there's also a large pool of React web developers, and this could be a way to encourage some of them to adopt something that looks like the stack that we have at Meta for the web because they can get native for free so to speak, as an experiment out outside where if you wanted to bring your web app to native, you have an option to run that code natively instead of as you were saying before in a web view where it maybe doesn't quite feel right or a team that's building part of the native app that you have difficulty interfacing with that web code. And so there's a lot of things like that where directionally this is an interesting exploration for us and it'd be interesting to see who in the React native community or even the web community is interested in this directionally as well. And if it does appeal, then it's something to check out and help us figure out from where we go from here.

Jamon Holmgren:

By the way, quick syntax question, can you import so that you can just use DIV and not html, do Diviv just to clean up your JS X, can you import or I suppose you could import and then export it from an intermediate file or something, but is that something that's doable? I assume

Nicolas Gallagher:

The magic imports like React on does?

Jamon Holmgren:

Yeah, maybe something like that or basically could you use React strict on with just Diviv instead of h ml do Div?

Nicolas Gallagher:

Well, as an import, obviously reactive constrained with wanting to have a capitalized

Ladder. So if you want it to look like Webby, like lowercase, you probably can't. And I think one of the reasons that I'm not a huge fan of doing the magic imports is because it can be confusing if you're a web developer and you come into a file and there's a div but it behaves slightly differently or it has a overloaded prop that takes in these different types of styles. And we even have some files where there's kind of a mix and match of React on and react strict on. So just in terms of clarity at this point, it kind of wouldn't have made sense to a match anyway. Other people can make their own choices, but it didn't feel like it would've made sense to overload react on or create some alternative thing that looks a lot like React on, but actually isn't

Tyler Williams:

Sure. That makes sense. Be harder for static analysis too. If you're linting across all of a sudden a div isn't quite a diviv and especially if you've got those mixed in the same file.

Nicolas Gallagher:

Yeah, that's a really good point. And we rely so much on code mods and Slint rules. Yeah, all these sorts of topics are reasons to keep things explicit.

Jamon Holmgren:

Has the new architecture made a in React native, has that made a difference for React strict arm at all?

Nicolas Gallagher:

Oh yeah. I mean I don't think React strict arm is possible without the new architecture.

Not really because we make a view look like a div or whatever, but because the ambition is to be able to run more and more of the web code that we have on native. And so things like being able to have synchronous events, the Event Loop model, intersection observer, all of these capabilities depend on the new features of the architecture and the successful rollup that they've had. So yeah, I mean all of that is foundational. This is React On is a layer on top of all of the work that the React native team and the community have been doing. It's an example of the kind of thing that's possible because of the progress that's been made on React native. And it's more sometimes people have asked things like, I don't want to give up my React native js, I don't want everything in React Native to be like the web. And my answer is that this is more like a layer that you can build on top of all the stuff that is React native. React native is not really the view text JavaScript components. It's

All the machinery that allows you to bind that JavaScript and have React run it, and then at the other end comes native code. And so React strict on is an example where, hey, one of the things you can do with React native is create this layer that looks like the web and behaves like the web at least aspirationally in the future. And that allows you to bring potentially this vast volume of web code onto Native. And that's like a new pool of developers in new opportunity. But if someone wanted to build something completely different like a Swift UI for React on top of React native, whatever it is, people, as you said with our tree platform, all these possibilities are still there. This is just one that I've been exploring with the web team.

Jamon Holmgren:

Yeah, totally makes sense. And actually that's a great segue into speaking of layers on top of it, but I guess two things. One is library authors. Is this something that they should be really seriously considering as a dependency of their libraries? Like, Hey, we're going to target React strict dom if we're building components and whatnot. And then secondly, what about Expo? Is Expo in the, is it possible to use this with Expo? Does it work well with Expo? Are there any considerations around that?

Nicolas Gallagher:

Sure. On that topic of expo, the example app in a React strict omni repo is built with Expo. It's one of the things that I wanted to make sure from the very beginning, but it's the easiest way for us to set up demos of course for our own integration testing. But as you said, expo is such a critical part of the React native ecosystem that making sure it works there is important too. I think longer term, if this were the direction that things went in, there's obviously things we could work with Expo to improve. Expo has, when you want to build web apps, it has React Native web as a hard dependency, even if you're not actually using it because you'd be using React strict on, but the reality is that React strict on is still pretty early and there are gaps and details that haven't been figured out.

Whereas Expo and the rest of the community who's doing a mix of native and web development using React Native have spent a lot of time yet building out third party libraries, building out integrations, all kinds of details that don't exist yet for something like React strict on. So I think it's one of those things where, as I said before, if it's directionally what people are interested in, then it's something to explore and it's relatively early, so there's a chance to contribute with surface bugs. I don't know, surface details, anything like that. I think my personal opinion and what I would say professionally are two different things. I wouldn't say to someone who's building a business on top of something like, oh yeah, sure, just jump on this new thing. It's really something more for the early adopters, the people who like to explore things and he might be excited that this possibility, especially if they came from a web background to React native as opposed to a native background.

Robin Heinze:

So I mean, you've already sort of touched on where I was going to go next, which is that we included, and a lot of developers we know are already very invested in reactive for Web. We have clients that are essentially mobile first. Their mobile app is their focus and they have a companion web app and Reactin IT for Web has worked very well for that, getting a lot of a web app for free. What's your recommendation for people? Do they continue using React unit for web? Is React unit for web even going to still be, do you anticipate it still being supported and stable for the companies that are pretty invested? Or is this something where they should start planning on how to migrate and if so, what's the best plan for that? Developing in parallel, going in phases, doing it all at once, what's your answer to those people who are already very invested in React native for web?

Nicolas Gallagher:

Well, if you're very invested in React Native, I would say keep doing that. And if the web is a kind of companion app, that's a nice to have up the side, then yes, that's what React native for web is for these days. I think there are things from the perspective of being an engineer at Meta, there are things that I'm thinking about which is there are legal requirements now to have certain accessibility standards

Robin Heinze:

For what kind of web apps that Meta is putting out. They're very high profile, very lots of scrutiny.

Nicolas Gallagher:

Well, yeah, I mean technically everyone is responsible for meeting these requirements, not just on Web but on Native as well. And I do know that it is possible to have those web apps that get spat out of React native code. They just won't meet those standards unless care is put to go back into the React native code and whatever, add the area props or other details. So I think there's always work that has to be done for web on the React native side of things. And so as long as people are on top of that, I think that stack is fine for now. Obviously long, I think to the point that's been brought up earlier where wouldn't it be nice to have them react one way to write React, which way should that be? And I think the way I see it now is it's easy to make a case for if there's going to be one way that the default way that you write stuff, having it based on the web is about a starting point, and then native specifics can be added as extras on the native side using all the tools. We have file extension to

Module loading, turbine modules, all that kind of stuff. You can augment it on the native side as you please, but in terms of what is the shared code that you can run anywhere, I think it's, it's going to be easier to say that it's based on the web instead of based on React native just because of the size of the developer ecosystems on both sides as well. It

Robin Heinze:

Makes a lot of sense. Everything you said, I think there was a little bit of anxiety among our team, among other teams, just that when saying, oh, that React strict Tom is maybe preferred in terms of Meta's viewpoint, that that would mean that React needed for Web is somehow in jeopardy of not being maintained or not being a stable solution anymore. It sounds like that's not necessarily the case, it's just you have to evaluate what makes the most sense for your business. And

Nicolas Gallagher:

I mean React native for Web has never received investment from Meta even while I've been at Meta. It's something that I've largely worked on in my free time. And so going forward, I still recently Expo wanted certain patches put in there. I think maybe for React 19 upgrade order, so when Paul requests or specific things like that come in, I merge them. Basically if Expo says we need something, then I help them take care of it.

Robin Heinze:

I was like, how much have you personally worked with Evan Bacon?

Nicolas Gallagher:

Yeah,

Robin Heinze:

Because he probably, it's probably Evan. Well, because

Nicolas Gallagher:

There are close partners and they know what their customers need and what they're depending

Robin Heinze:

On.

Nicolas Gallagher:

And so we're never going to leave all of you hanging on that front, or at least, like I said, it's not that META'S investing in it, but Meta's happy for me to play this role when it's needed.

Robin Heinze:

They're not anti they're, they're not trying to kill it.

Nicolas Gallagher:

No, not at all.

Robin Heinze:

And it sounds like Expo is still pretty invested.

Nicolas Gallagher:

Yeah, I think both. What we have now is essentially two different ways to do a similar thing, which is we're trying to share code. One of them is you start with React native code. The other is you start with web code.

Robin Heinze:

Yeah. It really is just coming at the same problem from two different Exactly.

Nicolas Gallagher:

And the solution is very similar technically as well. It's just different. And so both of these solutions I think will be around for a little while because the one that Meta's investing in is trying to get web code running on native. Obviously the ecosystem outside of Meta has this tool to bring the native code to Web, and I think it'll be on us to work with all of you, everyone who's in the community to, like I said, figure out if this is direction where we want to go, what are the steps that we take? It's not going to be some rapid switch over or suddenly Grant native for Web is deleted or anything like that. I think the reason I wanted to open source it so early on was because I wanted the community to see what was being done and if there was interest out there for that to motivate people to get involved, or even if it's just the surface, the desire to have some of these capabilities built into React native itself.

Jamon Holmgren:

Yeah, I think when news kind of got around that you were joining Meta, that was considered a really good thing because it meant that React native for web and just sort of the thinking about React native and web and the interop and making sure that everything worked really well, that that was something you were passionate about and that you'd be able to keep doing it over at Meta and have probably a little more influence there, a little more access and whatnot. So those of us in the community, we definitely really appreciate all the work you've done, Nicholas, I know it's been a tremendous amount of work. I'm sure at some points you've thought about deleting the ING from open source

Robin Heinze:

Maintainer is not for the faint of heart. I'm so sorry.

Jamon Holmgren:

Exactly. It's so much work in it, especially when you're

Robin Heinze:

Dentist source. It can be unfortunately very thankless,

Jamon Holmgren:

Which

Robin Heinze:

Is sad. So we're thanking you right now.

Jamon Holmgren:

Bump, bump, are you done yet? What's any updates on this? What's the status on this? I need it. It's like, alright, this is open source. If you really need it, you can fork it and just make it work. Right?

Robin Heinze:

We're open a pull request.

Nicolas Gallagher:

This is why I was looking at the React core team because when I first joined Meta, I spent a bit of time on the core team and I was like, man, it's so nice. React on really doesn't need much maintenance. Every now and then the browser adds a new prop and then that gets added. But otherwise compared to React native and reactive for web. So that maybe got me thinking. I was like, well, if everything could be based on the web, the maintenance costs would go way down.

Robin Heinze:

Yeah,

Nicolas Gallagher:

The

Robin Heinze:

Web's been long figured out.

Jamon Holmgren:

Yeah, exactly. But yeah, appreciate everything and yeah, if people are interested in learning more, what's the best place for them to go for Rec Trium in particular,

Nicolas Gallagher:

The GitHub repo and the documentation website, I think have as much information as I am aware about there. If there's anything missing, just post an issue or start a discussion and we can add to it.

Jamon Holmgren:

Perfect. Yeah, we'll put links to that in the show notes. And thanks so much for coming on. Really appreciate it. Nicholas, it's been probably well overdue to have you on this podcast. Hopefully we can have you on again in the future and talk about whatever you're working on at that point.

Nicolas Gallagher:

Thanks

Robin Heinze:

Having me.

Jamon Holmgren:

Alright, that's all the time we have for this episode and so we'll see you all next time.

Robin Heinze:

Alright, bye everyone.

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 coordinat or, 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.