Todd Werth:

Welcome back to React Native Radio Podcast, brought to you by Open AI's legal team. Did you know that Deep Sink stole the IP we already stole? Just not fair. Episode 3 21 Expo Dom with Evan Bacon.

Jamon Holmgren:

Hey everybody. We're back with another React Native Radio episode. I'm Jamon and I do not have any of my lovely co-hosts with me. Mazen and Robin are off doing. I have no idea what, they're probably just goofing off while I'm here, stuck in this chair having to sit down and actually talk about stuff that I really enjoy talking about. So I'm happy and I'm not alone. I actually have with me Evan Bacon. Evan, thanks for coming on. I really appreciate it.

Evan Bacon:

Yeah, thanks so much for having me again. It's always a pleasure talking with you.

Jamon Holmgren:

One thing that's always awesome about doing podcasts with you is I know that I don't have to carry the conversation too much. You have such great insight into React Native. You're always working on something interesting and yeah, I don't know. I'm looking forward to it. It's going to be a fun one. Before we get into that, I do want to say that this episode is brought to you by my company Infinite Red. We are Premier React native consultancy located fully remote in the us. We have 30 senior plus React native developers and support staff and have been doing this for nearly a decade. Why does it say nearly a decade? I think my notes are wrong. It's 2025. I need to update that. It's been a decade now, so I should update that. If you're looking for React native expertise, hit us up at Infinite Red slash Radio and don't forget to mention that you heard about us through this podcast. Alright, Evan, we're going to be talking about Dom components in React Native and we're going to, I mean some people in the audience have probably been following along with you on Twitter and probably understand what you're doing. I mean, I guess for the folks that don't know Evan Bacon, no, this is not the actor. Kevin Bacon. This is Evan Bacon.

Jamon Holmgren:

I'm sure you've gotten that joke plenty of times.

Evan Bacon:

No, first time actually. That's crazy. Who's Kevin Bacon? No, no,

Jamon Holmgren:

Exactly. And he works at Expo and he does all kinds of cool stuff. I don't know, Evan, can you just really quickly list off all the different things you've been involved? Not all of them, but just a list of things you've been involved with at Expo and otherwise?

Evan Bacon:

Yeah, yeah. So I'm creator of Expo Router, which is our navigation solution, which is the universal framework. Let's see, before that I rewrote the CLI before that I a pre-build. So I think my first really big project at Expo was just getting rid of the eject command with expo eject. Just leading that. The

Jamon Holmgren:

In this eject? Yeah. Yeah,

Evan Bacon:

Just removing that and replacing it with the system that has none of the same limitations. So you can use any custom native code and you get smaller apps and then worked on off session and some of our authentication stuff and now I've done DOM components and working on server components and expo as well. I also made Expo web out the web platform and been working on trying to really get that to a place where Expo web is really one of the best possible ways to build a website and we're making really great progress on that, but also just bringing a lot of the web, the good parks, keeping that alive and well and React native. But before that I was just iOS developers, so I'm definitely very much fascinated by mobile development and apps that kind of travel with you.

Jamon Holmgren:

Yeah, it's fantastic and you've given talks about some of these things over the years, so I do encourage people to go look those up. I recently found out you have a Wikipedia page and it's not even for your development work

Evan Bacon:

Apparent, apparently

Jamon Holmgren:

You were Lego, a Lego artist, is that what you

Evan Bacon:

Call it? Yeah, yeah. Its like Lego art. I think when you work at Lego, you're a proper Lego master builder, you a profit one. But yeah, it was just something I did as a kid wanted to build. I was fascinated with the idea of just building large scale Lego statues and sculptures. I think I saw just some video or something, whereas they did the de resing and you notice that it's like, oh, you can create a circle with jagged edges if you just squint or whatever. And I was like, what if you did a whole person with that? So I did that from 12 to 18. But yeah, I might get back into it. I dunno, there's a lot of interesting things to build.

Jamon Holmgren:

Wow. Yeah, I mean there's probably some parallels there. There's probably, you're building things with components and you're kind of composing it together from smaller pieces. Yeah, it seems like it just kind of fits.

Evan Bacon:

Yeah, you just kind of chip away at the mountain, I guess. I have some of 'em stood up in my house. We got a big one back here.

Jamon Holmgren:

That's awesome.

Evan Bacon:

And yeah, I dunno, sometimes I'm also kind of blown away by it. So yeah, it was just like you can basically do anything if you really just stick to it long enough

Jamon Holmgren:

Story of my career. Yeah,

Evan Bacon:

Totally.

Jamon Holmgren:

Alright, let's talk Dom components. So first out, can you kind give for people who aren't familiar with this concept at all, obviously they're listening to React Native radio, they understand that React native is building with native views, like you write React and then it renders a native view from that and you kind of coordinate and orchestrate it from the JavaScript side of things. But what's a DOM component? What's this all about?

Evan Bacon:

Yeah, so Dom components are, it's a react component and at the top you market with a used dom directive, kind of like used client or use server,

Jamon Holmgren:

Right? It's just like a string, right? Like quote used Dom quote, right?

Evan Bacon:

Yeah. And then when you import it, it renders that component and all of its children inside of a web view using React native WebView under the hood. And the benefit of this is whenever I would use WebView, my idea of this is that it is like, oh yeah, you could just use React code in your app, but actually it's like a WebView ingests A URL or it ingests HTML. So all the modern standard features that you expect, the bundling and data fetching and being able to handle aliases and typescripts, all that you have to do yourself. So with the DOM component, you can share all of your existing BUNDLER code and utilize that from that component down. And what's really fantastic with this is that you can basically just take your website and immediately run it on native instead of a DOM component, similar to one of these old school web view approaches like phone gap, but without the major major drawback where with phone gap, you would have to start from scratch and just kind of throw away everything that you did.

Evan Bacon:

With this, you can go up the component or down the component, you can go whichever way you want through the component tree incrementally migrating components over to native. And then if you're using expert router, you can go route by route changing the routes over to native. So if one screen is working just fine for you as a web view, you can leave it that way. But if you want to change your main page, you don't have to start from scratch and learn a totally different system. So yeah, it really takes full advantage of reacts composability model to jump between the boundary of native and web.

Jamon Holmgren:

We're going to talk a bunch about incremental migration for sure, but before we get there, I want to make sure that we're super, super clear here on exactly what's happening. This is running in a web view. This is not translating web code into native views. This is taking basically web code and using it on web as a web view. Now is this local? It's not pulling from some server, right?

Evan Bacon:

Yeah, currently it's all local. So at build time, this is actually probably the hardest part to get right, but at build time it will bundle each DOM component separately and then embed them inside of your app so that they just load from disc and then take all the assets that you acquired and pull those in as well. But yeah, it is all web code. And this is kind of part of maybe a larger migration story. If you think about React strict dom and this idea of universal div and universal image, those won't support every possible thing that the browser can do because if they did, you would effectively just be rebuilding the browser.

Jamon Holmgren:

Rebuilding the browser. Exactly.

Evan Bacon:

And the browser's already very optimal at doing what the browser does. And so there are going to be trade-offs. And so when you combine something like DOM components with strict dom, you get this flow where you can see strict dom runs on webs. You can convert your code to Universal inside of web, and then when you remove the directive, you can immediately see if it works on native and if it just blows up and there's all these errors and you're like, okay, nevermind, you can put it back and continue migrating on the web space. So it really helps streamline this migration from web over to native by having it share as much as possible. It's all the little things that you don't think about. It's like environment variables are missing, your Ts, confi paths are missing. Any custom aliases you set up are missing. So all of those are totally shared. All your deployment and build is shared. It really just comes down to the components being different and some of the styles which when you isolate it like that speaking styles, it's super easy to wrap your mind around that migration.

Jamon Holmgren:

Speaking of styles, you have CSS, is it an external file? You're just using regular CSS or what's going on with that?

Evan Bacon:

Yeah, yeah. If you're doing styling in a DON component, it's just, it's totally web. So you can use anything that Expo web can do. An expo web is a super high powered web framework at this point. So you can pull in inline CSS, you can use global CSS, you can use CSS modules, SaaS, post CSS, tailwind, anything, and we're adding server functions to it as well. So you'll be able to do server rendering inside of them as well. So you could really just take modern react code from any framework and then put it inside of your app and migrate it over to native.

Jamon Holmgren:

So I, along with Tebow, was involved with the React native WebView for quite a while now, Tebow does almost all of it. I don't do a lot of it anymore, but the React native WebView is, it's a big beast. There's a lot to it. It's got a huge surface, API Surface area. There's so many different things you can do with it. You would think, oh, I just drop in a WebView and then I have all of the browser features, I have all the, and it is just not true. A WebView is not a browser, it's not even close to a browser. There's so many things that browsers do for you, just as an example, cookies, it's just not built in. You have to actually build cookies around it and WebView has an implementation. It's not, well, okay, I'm not going to get into all of the details, but WebView is kind of headed that direction, but there's just no way that you can provide everything a browser does in the WebView even if you're not handling the rendering, even if you're allowing the WebView to do the rendering. So knowing that, I have to ask you, did you use some specialized stripped down Evan Bacon infused version of WebView or are you using React native WebView?

Evan Bacon:

Yeah, so behind the scenes there's actually, there are two different web views that you can use. One is experimental, it's something we've just been playing around with. And the other is the default is really at native WebView. And to your point, it is very large, but web views kind have two purposes. One is this embedded content flow and the other is this remote flow. And so you have all these permission, you have all these API interfaces, things where it's like location, permission allowed and tons and tons of location, different types of permissions that you can turn off. And those don't really make sense in the context of embedded content, all your own content, they make a lot of sense when you're loading someone else's website and it's like you could navigate anywhere, so you're not sure what might be loaded, so you may turn everything off by default.

Evan Bacon:

So in DOM components where we do use this embedded flow, you can think of it as a much more stripped down version of what users will end up needing from the web view. So we can turn a lot of settings on by default or off by default and have a much more opinionated interface. So I found that simplified things because a lot of this, when we were first playing with the idea, there'd be little things like the scrolling is just not quite the right velocity or acceleration speed as you would expect. It's some different value. So we try to really match it to a much more opinionated set of rules so that you just get what you would expect, for example, what you

Jamon Holmgren:

Would expect. Yeah,

Evan Bacon:

Scroll view in iOS and native, it doesn't by default account for large header and then built-in navigation footer, and so you have to go in and set prams for that. But DOM components do so they work better with other native components. We'd really try to make it feel as native as possible, even though it is a web view, just so that you get something that you feel generally proud of so that you feel more motivated to migrate to native. You're like, oh yeah, you know what? I'm liking this native scroll feel. I like the way it interacts with other native components. You do get one native scroll in a web view, at least on iOS, the body scrolling is a UI scroll view. You get the one, so you got to utilize it correctly, right? Yeah. Everything else is the JS scroll and it is noticeable, very noticeable.

Jamon Holmgren:

And that I guess brings up a point, I thought we were trying to get away from this. I thought that doing web views, that was the enemy. That was the thing that everybody said we should do, and then it just didn't work. So why are we going back to this? This feels like a step backwards. Why would you ever do a web view in a React native app?

Evan Bacon:

Yeah, yeah, great question. I think that if you look at someone who goes from maybe not being a developer to getting into making apps, then maybe they try a web view approach and then they get really burned on it because the only way out is to start from scratch and then they find a tool like React native. This gives you a much more incremental and smoother bridge over just because you're already able to, with React native, pretty specific, three eight native, a lot of ways write really high powered native apps with JavaScript. So we're able to leverage that on both sides of the WebView aisle and the native aisle. But then also there are elements of WebView that just feel like frankly really bad, at least as of today, regardless of your approach, your mix match approach. And the main one is navigation. Getting the right navigation goes a really long way into making your app look and feel really native.

Evan Bacon:

So with Dom components, we actually restrict a lot of the navigation and we try to make it just like a standalone component. And then you can do things like access expo, routers link component to move between pages, file-based router, and when you call those, they send a signal up to the native app and then it navigates using native navigation. So we do try to enforce that you have native scrolling, native navigation and really just as much native as we can without being too scary, too heavy handed with how native stuff works. And then it does have this kind of cool ability to pass data back and forth. So a WebView doesn't have access, for instance to native haptics, but with DOM components you can just define a function as a component on that component and then it can call haptics, and then you can ingest it and call that function and then it will make a haptic effect.

Evan Bacon:

So we have some sort of serial transport layer, which is asynchronously passing values back and forth between web and native, which is then fully typed because of how hidden away this is inside the bundler. And then that allows you to make your app even more native. So for example, say you're building, we'll say you already built a website like a blog or some sort of maybe cooking website and it's really popular and you got a lot of users and you're like, okay, I want to make this an app. I want to send users notifications or want to have live activities come in. You don't have to start from scratch and then re-implement your CMS or whatever you're using to do all the data fetching with Dom components. You can just run it in your app and then expose just the notification functionality and you can try it and you can be like, okay, does this make sense? And if so, if it doesn't, then you can just stop right there. And if it does, then it's like great. Now you can start migrating over more and more. So you get this really fine intention driven pathway to going from idea to full fledged product.

Jamon Holmgren:

That sounds really cool. Can you actually just define an async function and then just call it from web and have it just run in native, or is there a little more wiring up that needs to happen like that?

Evan Bacon:

Yeah, so you just import the component. If it says use dom at the top and then you define as a prop, you could have on press as

Jamon Holmgren:

A prop. So you pass it in as a prop.

Evan Bacon:

Yeah, as a prop to the do component. That's super cool. And then it ingests the prop and you can call on press and then it will do whatever is on the native side.

Jamon Holmgren:

It just has to be async though, right?

Evan Bacon:

It has to be async and then the props, so it can also return value, so it can take prams and it can return values. Those all have to be serializable because it's going over a serialized async bridge.

Evan Bacon:

So you can't pass complex data types, which I think is fine because that also helps a lot with the migration of going from web, if you really start to dig in and it's, you're like, oh, well. So we try to keep it a tester, like a light feeling where you can move back and forth. But yeah, it's really nice to just go from web to trying a native API. In many ways it feels like a composable browser where you have your web, all your browser features, but you just need that one new iOS feature and give it a shot.

Jamon Holmgren:

Do you think there's ever any hope that you could do a synchronous call, do a

Evan Bacon:

Bridge list almost? Yeah, so that is where you mentioned having a custom web view. We do have this experimental web view that Chen built where it can instantiate, for instance, Constance onto the module in the global scope, and then you can just import expo modules directly without having to go over the boundary. It's all very experimental. This did technically work. There's a history with iOS web views where there's the WK web view, the more recent one, and then before that there was UI web view, and with UI WebView, you actually had access to the global, and you could theoretically do JSI with it. You could just install that native models. Yeah, theoretically you could just install things right onto that global with the new one, everything has some sort of similar transport method with WK WebView, so you don't actually have direct access to the global, so you can't install methods right onto the global. If we built a custom web view on iOS, we could. And then on Android, this is possible,

Evan Bacon:

Again, it's very similar to the fundamentals of React native, where React native has a global, which is then shared and you can install functions on it using c plus plus. And yeah, that would technically work with the web view as well. But again, this is just a nice way to migrate over. We don't need to turn this into super crazy tech in a lot of ways. This isn't, I think if I were to had this idea and then gone out and built it from scratch, it would've not really made a lot of sense. It probably would've taken maybe eight months to a year to get working because a lot of the magic is less about the serial transport layer and how used DOM works. A lot of the magic is universal Bundler and Expo CLI being universal, and the fact that the same dev server has this multidimensional graph where you can request with different parameters and then the bundler will change its transform and resolution serialization to return a web bundle from the same code base or an iOS or an Android bundle. That's where it's like the, for instance, if Expo Web didn't have CSS, then we would have DOM components, but you wouldn't be able to use CSS in them. They would just be limited to style sheet. And so it's really DOM co is kind of a combination. All these other incredible technologies that we just have kind of lying around inside of Expo CLI and mixing them together.

Jamon Holmgren:

Yeah, totally. And I do want to keep the audience informed that really what we're doing here or what you're doing here is you're making it so that that migration is easier. You're not necessarily trying to make a competitor to react. Natives, renderer. You're not trying to, you wouldn't start an app. Well, I don't know. You probably wouldn't start an app and just be like, I'm just going to make all these used dom components and have the whole thing orchestrated so that basically you'd have this kind of mix between WebView and native from the start. It's really more when you already have a bunch of components, you already have some things that work. They rely on web technologies, and so converting them to native would take a tremendous amount of work. So what you do is you start with, okay, well we'll just put 'em into the native app, into their spot, into that rectangle that we put in this tab view into this drawer view, whatever.

Jamon Holmgren:

We stuck it in there. And then when we're we ship it, right? Usually what's going on is we have a ship date, let's get it done. Boom, we send it out there and then we're like, okay, I'm using the app. This screen doesn't feel as good as it should. Let's do that screen, let's make that screen better. And there's some screens you never touch, you never touch again. They stay in WebView. They can stay in it WebView because 1% of your users use it once a year. Who cares? That screen needs to exist, but it doesn't need to have that same level of experience. And then to be honest, there are some views where WebView will be just fine. It will actually perform in a way that you wouldn't even notice. There's not enough animation, scrolling, whatever interaction with native stuff. You will never notice that something is a web view in those cases. So why invest the effort you already have the component built. That's essentially what we're talking about here, right?

Evan Bacon:

Yeah, definitely. And I appreciate all that, the extra nuance. Yeah, it is tricky to get this story exactly right. But yeah, and it's not like a one size fits all. It's very much like react. There's lots of different ways that you can use it, utilize it, because like you said, there are some cases where Don components are actually in some ways maybe closer to what you want. So for example, if you were rendering markdown, like Don web views, just have a lot of that view recycling built in. If you were rendering a rich text editor, a lot of rich text editing is pretty gnarly. And when you start building it out natively, you start to realize, oh, this is actually very similar to what a web view is doing natively. Maybe the web view is good for something like this. And especially if you measure time versus complexity, then maybe it does make sense to ship maybe Rich Tech centered very quickly with a DOM component and then move over natively if you're seeing that that feature is actually working and gaining traction.

Evan Bacon:

So yeah, it really just depends. And we just want people to have another tool in their tool belt. Really the only interface for this is you add used onto the top of component and it just turns on immediately. You don't have to install another bundler, no extra web setup. Everything just starts magically working. And then if you want to turn it all off, delete the use dom directive and it turns all off, which is pretty fantastic. And it also helps library authors and React native a lot as well, because you can get a sense for areas where the web is just really nice compared to Native and very compelling in how some of the components and styles work when it's right there. And you can be like, okay, well when I migrate this over, I see that there's these two or three things which are hard to migrate over.

Evan Bacon:

Maybe it's like CSS filter proper or something like that, and you're like, I really wish we had this in native, and then there's no reason not to add it to native. So then you do. So bringing the Web DX really as close to native as we possibly can, I think will help us identify many more of these missing props that we just want universally. Or maybe you start to see the different flex differences. You can write React native web code inside of a DOM component and then just delete it and then it will immediately start working theoretically and React native, but maybe the flex styles are slightly different or slightly off, and you can identify those much more quickly when you're just deleting and adding the used dom direct.

Jamon Holmgren:

That's a really good point.

Evan Bacon:

So I think this will definitely encourage much better native experiences as well. And then in general, we also just want to kind of grow the pie and the metaphorical pie, and I think a lot of people who are already building React native apps today, maybe some of them will benefit from this, but a lot of this will go to benefit people who have wanted to get into React native but have just found it maybe too tricky to get into or maybe a little hard to find their footing. There's just hundreds of millions, maybe billions of websites out there. There's incredible content out there. So if you could just run it as an app, maybe you'd be like, okay, maybe this does make a lot of sense to an app, and then you start to get into it. How I find I code the best is when I build something and I get that kind of instant gratification from it, I'm like, oh yeah, this is good. It feels good. I can ship this to someone, they can try it. And then I get hit with, I want this to look and feel really good. I don't want to be embarrassed by the quality of it. So yeah, I think this just enables all that.

Jamon Holmgren:

Do you envision this mostly being used for full screens or could you see a native screen have 20 little dom components being rendered?

Evan Bacon:

Yeah, you can definitely do that. WebView are powerful enough for that specific because of that WK WebView UI WebView transition that Apple did. So they do leverage a lot of the same resources behind the scenes. So yeah, I could definitely see that happen. I built a DOM component the other day where I wanted this cool blurry pixelated gradient at the bottom of my scroll for a chat app. So when I scroll through, it gets incrementally more pixelated as it goes down. And I wanted to use all the background CSS filter props that are available, didn't work exactly the same way because it doesn't know how to blur across the different layers, but it did mostly work, which was fantastic. So in that case, I'm just using it as one component that I'm absolutely positioning over content that is scrolling natively in the background. It's also great for just different background views.

Evan Bacon:

If you want some cool dot pixel grid in the background and then you just want to absolutely float it, you can do that too. Maybe there's cases where, like I said, like a rich text editor, you just want native scrolling, but you want a rich text editor section in there. You can make that a DOM component. It's a very lightweight web, so we keep it very, very, it doesn't even have built in ran native web support. It's just strictly react. And there are some caveats to this. So for instance, every web view has its own global state, so they don't share a global, and then they also don't have access to react context. So once you get up to the react context on the native side, you access the context, then you pass it through as props to the DOM components

Jamon Holmgren:

As a prop. Yeah,

Evan Bacon:

Exactly. And then that

Jamon Holmgren:

Across that boundary, right,

Evan Bacon:

Exactly. We could probably figure out some way to send it over the boundary, but I think, yeah, we'll just maybe down the line. I think we'll fill this out, see how people use it. Also very new, just came out with 52

Evan Bacon:

And so yeah, it seems like people are really enjoying it and getting some pretty good use. I just saw an example of this group in Connect use it where they have a website and they have this D three Gantt chart. It's super interactive, but it's also very important to their website and their product, and they were stressed about how they were going to get that working on native. They also, they're actively developing it, right? They're constantly making it better. So DOM components came out just kind of at the same time, they were able to just pull it into a DOM component and ship it.

Jamon Holmgren:

That's amazing. That right there, listeners, listen to that story right there, because to me that kind of just showcases the power of this. Even if that was the only thing it could do right there, that's worth it. Because right there, they're looking at how long will it take to recreate this in React native? And then also it's changing out from underneath us where, okay, no, no problem. We put that one in, we ship it, and then later if we're like, okay, well Web isn't really doing the job, then we can take our time and do it right and then swap it out when it's ready. It just allows you to do those types of things. I remember way back in the day when I was just not a native iOS developer, and this was early days. I had this one small view that these days would be pretty easy to implement in native, I think, but it was sort of like a tag cloud type thing, and I needed to, it was just a part of a bigger screen and I could not figure out how to do it in native. I was doing a bunch of math to try to, I was basically trying to almost make a yoga layout system,

Jamon Holmgren:

And then I was like, you know how easy this would be with just, I mean, it wouldn't have even needed Flexbox, it would've just been the old float system, just float it. And so I stuck a web view in there and I just did that. And it wasn't even a thing that was like interactable, you couldn't touch, you couldn't scroll it. I turned off scroll. There was no way to tell that was a web view at all. It was the same colors. You couldn't scroll it, you couldn't interact with it. It just fit right in and it saved me so much time. So that's a really early proto versions of this, but this is what we're talking about, these types of components where we've got it working on web, and actually we get asked all the time when people come in and they're like, Hey, we want to migrate, but do we pause development on our web stuff? We got to try to keep parody, right? But that's not realistic. So what do we do? And that incremental migration from web, we're talking web to a React native thing. It's like, no, keep it rolling. We'll just keep folding in the, we'll basically share the code and then when it's launched, we launched and it's ready, then we can take our time to go back and kind of improve the experience if we need to.

Evan Bacon:

Right? Yeah, I mean, you touched on this a bit, but there's this kind of function of complexity there where it's like if setting up a web view and getting the whole pipeline for distributing and embedding the web view content was part of the complexity that was required to use a web view, then it makes using WebView much less compelling. So now totally the DOM components, right? It's pretty equal. You just drop the directive in, you install React your WebView, and you're good to go for similarly, just turning it off, you don't have any extra bloat. There is zero bloat added by DOM components if you have zero dom components. There is another caveat there though. With web views, they load slower because it's standard JavaScript instead of a web view, whereas in Ran native, we have Hermes with bike code, so it parses that pretty much instantly, right?

Evan Bacon:

Like it memory maps it to life. And so you will see that. So I think apps that, for instance, maybe you convert all of your routes instead of expert router over to Dom components, then you will see startup take longer or it'll start up and you'll see the native navigation pop in and then the content takes a little bit longer and then it loads in. And so that's another really compelling reason to then migrate it over to native. And I think that also just punctuates how incredible React native is that we have Hermes bike code and that we're able to write JavaScript that just functionally is really great compared to Standard Web

Jamon Holmgren:

And we don't want to make it too nice over on the website. We still want the native views. No, totally makes sense. So what do you need is, okay, first off, can you use this without Expo? And then if you are using Expo, what do you need in order to enable this and just start using it?

Evan Bacon:

Yeah, so like I said, the magic here is really pulling a bunch of expo pieces together. So you need Expo CLI and then Expo's, bundler setup, which is the default, and instead Expo CLI. And I highly recommend that just because if you're using Metro Expo is the best way to use Metro, and then you don't need to use Expo Router. It's not explicitly tied Topo Router, but it does have some nice built-ins with expert router, like for instance, navigation and that's it. So if you were just on the Blank Expo project today, you could install React native web View, add use dom, and then that component will be a DOM component and you're cooking if you want to build and deploy it, you can EAS build, send it right off, and then it will take care of packaging up all of the different DOM components and then embedding them in the binary and pulling them back out from the local file system in production. One thing that people should do if they're interested in this and doing that migration is migrating from not expo web to expo web, which is a very easy, it's easy to move between different web frameworks much easier than Native frameworks. I mean, that's like years of work to move between native frameworks as you guys well know.

Evan Bacon:

But yeah, on the website, expo web works functionally very similar to most other React web frameworks. And so if you're using that, then you can just turn it on and off as you see fit just by sheer nature of needing the universal bundling and the universal components. One thing that I really like about this is I think there's a lot of flack with React Native web, for example, because it's not as optimized, it's not as lightweight and as nice as just using React dom directly. And that is totally true. There's value to things like React native web's view image, and what's nice is if we can amplify that value and deliver that value to people when they want it. So with Dom components, you could just start a website with Expo today and use div P image span all just go full web, don't think about Universal at all, and then you can migrate it over to DOM components and run it on native.

Evan Bacon:

From there you'll be like, okay, this is great, but it's starting up slow. I really wish that I could share code and I wish I could do this view or this image or this text universally. Then you start to see the value of pieces like React Native Web at that moment, which is not at the beginning of the project. It's not when you're testing or trying something, it's kind of more towards when you are migrating and trying to get into new places. So really meeting users where they are with the framework I find is really important. So rir Web still very important, but it has had this kind of quandary about when it's valuable to you, and I think Dom Quin helps mitigate a lot of that.

Jamon Holmgren:

It absolutely does. Yeah. This really kind of removes so much of the friction, and it also kind of makes it so that your early decisions in a project are not so consequential when you know the least.

Evan Bacon:

Right? Yeah, I mean, when I got into software development, that was always such a pain to me was like you have to decide early on is this product good for web or native because that's a road that you can't easily come back from. Now it's like with Expo, you just go whichever direction you want and you can aggressively reuse components in different platforms, and you can start with Diviv and Span and migrate all the way down to Swift ui, custom UI views on an iOS device with the latest content. So yeah, we really don't want to punish people for just shipping as quickly as possible and trying to build something that makes the world a better place around them.

Jamon Holmgren:

So unfortunately we're out of time, but I have one more question for you. When you were making those giant Lego sculptures, did you ever get to a point where, I guess I assume you're starting at the bottom and kind of going up, but if you were making a giant, I don't know, I'm just like a giant bear or something, you ever have to be like, oh, I got to take this whole thing apart. I started wrong. The bottom is not right.

Evan Bacon:

So I would plot out the center of gravity, the hardest part to get right, and then I would build freehand larger sections maybe in horizontal slices, and then when I was sure about the shape and generally what I wanted to do, or at least 80% sure, then I would start going from the horizontal layers from the ground up, gluing it as I went, and yeah, you'd make some mistakes.

Jamon Holmgren:

Oh, gluing as you went.

Evan Bacon:

Wow. Yeah, I learned retroactive light. I probably should have used something like acetone to kind of dissolve the bricks together because then it's a stronger fit and they don't move over time shift, but live and learn. It's probably for the best that I wasn't dissolving a B, s in my room as a 14-year-old, I probably would've got brain damage. So be careful with that stuff. Guys. Use a mask and have good ventilation.

Jamon Holmgren:

Oh my goodness. Yeah. Well, thanks so much, Evan. I know there's so much more we could talk about with this topic. We barely scratched the surface. There's so much more kind of depth to this, but Dom components are really cool. I think this is a huge step forward for the React native and expo communities, and I can't wait to use it on something. Really appreciate you coming on, and of course if you want to follow Evan, you can go find him on Twitter at Bacon bricks, which I now realize has to do with his Lego.

Evan Bacon:

Yeah, it is a Lego reference. I made it when I was

Jamon Holmgren:

Bricks as in BRIX, I believe, right?

Evan Bacon:

Bacon

Jamon Holmgren:

Bricks. Obviously you can follow React Native radio also at React native R dio, you can go to GitHub and follow him there as well. He does all kinds of cool stuff, so go check all of that stuff out. Yeah, thanks so much Evan, really appreciate having you

Evan Bacon:

On. Yeah, thanks so much for having me and thanks for maintaining React native WebView. It's fantastic library.

Jamon Holmgren:

It was fun. I do have to give credit to Tebow who has been really the driving force behind it in more recent years, and there's some others as well have been involved. It was fun. It was challenging though. That thing by itself is almost its own framework I guess. So yeah, that was an interesting kind of chapter. Alright, well thanks a lot everybody, and we will see you all next time.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, 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 https://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.