React Native Everywhere

Lovely.

Thank you so much.

and as mentioned, hey there, I'm Taz.

I'm here to talk to you about React Native everywhere, and yes, when I say everywhere, everywhere.

Even down here with these lovely little penguins.

and for those of you that don't know me, I'm the founder of Guild.

it's the new platform that's in beta at the moment into elevating communities around the world.

currently we're focusing on events like the one we're at and presentations like the one I'm giving all hosted on the same platform.

So come chat with me later if you're curious about what we're, what, we're, building.

I'm sure you might have noticed by now my accent is certainly not from around here, and that's because I'm from Toronto, where I started the Toronto JS community back in 2010.

Back in those early days, I was subject to a lot of banter about JavaScript.

Oh, you aren't a real developer unless you program in Java, or C++ or .NET they used to say, and I was taken aback because if you've ever built a JavaScript application before, you know how much diligence goes into it.

Back in those early 2010s, we were just starting to build applications using underscore and backbone, which you remember those days, they were immensely complex beasts.

And so I started Toronto JS to get folks together to get them talking and elevate our craft together.

And a lot of what I did back then serve serves my impetus for starting Guild today.

And that's because I quickly discovered that communities are everywhere.

We're a similar community here right now.

And in fact, a lot of my closest friends I met via the community, some of whom are in this very room.

And so I packed my bags, moved to London 2017 to explore those communities around the world.

It is also then I was introduced to React Native on every platform, and you can see me here talking about that in London.

Just after I moved in 2017, this tweets from Ellie, an organizer of that event where I spoke and now a good friend as well.

You can find that presentation post on Guild by heading over to my profile, checking out the presentations I've given, clicking on six and one.

Take you to video of that talk I gave and you can see me talking about the magnificent Pontiac aztec.

I don't know if you get that car down here.

do you guys get a Pontiac aztec down here?

No.

Ah, you're missing out if you're not getting it down here.

That thing's amazing.

but to give you a quick rundown of that talk, essentially the goal is to have common code running on every platform.

Of course, every platform is different and requires unique consideration to properly address every platform.

That's one of the key strengths of React Native, is that can push that uniqueness to the boundaries and keep the core of your code base common for every platform.

Things like date selectors, file inputs, notifications, maps, and more can be addressed at the edges, leaving the internals of your application to focus on the common experience.

For us, an early stage startup, it's important to optimize for developer efficiency.

We want every change to our code base to have as much impact as possible.

We don't want separate teams working on each platform.

That will result in no co-sharing at all.

We don't want some sort of low level of co-sharing where some elements are shared, but the majority is still separate.

In an unrealistically ideal world, we want all of our code to be common for every platform, but that wouldn't address the uniqueness of individual platforms.

And in my opinion, react native makes it easy to respect each platform's individuality, by leveraging and leveraging that creates truly native experiences.

So realistically, we want the vast majority of our code to be shared across every platform, aiming for 95 plus percent code sharing and making our developers as impactful as possible.

Now, whenever I say this, folks look at me and say, but Taz, why don't you just write for, Web?

Because Web works on, mobile Web.

You can just run a browser on every platform.

And I say, unfortunately, 90% of users spend their time in mobile apps, only 10% in mobile browsers.

And so building a truly first class native mobile app experience is critical to properly engage users.

To say it differently, if I'm using Twitter on my phone, I'm opening up the Twitter app, I'm not going to twitter.com, and the Twitter app is where I spend 90% of my time.

So that's pretty accurate.

and so this really makes sense if you think about it, cuz Apple and Google are pushing for native apps on their platforms.

Their operating systems are geared towards this.

And providing an awesome native experience will be more optimal, for users at the end of the day.

Now, of course, go back, check out my talks in 2017, figure out how to set up the Web pack and all that.

from then, but these days, all of that just included an expo.

So go check out expo.

They packaged it all up very nicely.

check out their docs for getting up and running with this environment.

make any app, run it everywhere.

And so today I wanna focus about the next part of my journey, starting with responsive composition.

It's no secret that multiple form factors exist.

Obviously, when building an app that works everywhere, we need to take this into account.

You expect a platform like React Native to do this well outta the box, but it just provides the basic primitives.

Critically, there's no CSS.

That means there's no media queries, there's no CSS grid.

There's no CSS selectors at all.

There's no first, last, nth child support.

None of that.

And so if you've ever built a responsive Web application before, you know that trying to do it without any of these constructs is difficult.

And so what do I do?

fortunately, I went to consult in Bangalore back in 2017, and the organizers community there got ahold of me to talk for their community because communities are everywhere, after all.

And so I agreed, and here I am presenting on that Pontiac aztec, once again.

Truly magnificent car.

I got the pleasure of knowing the organizers of that community, and one of them is Siddarth, who's sitting next to me in this photo, and thank goodness for that because Sid has gone on to be one of the foremost experts in the React design system space, and I look up to him for knowledge in this area.

Around the same time in 2020 that I was looking for a solution for my React native application, Sid came out with React UI and this is taken directly from the React UI website itself.

It says React UI comes with a set of components that are accessible, responsive, and customizable.

That sounds like exactly what I want.

It also has a list of components it ships with, reading from the right.

There's element, link, select, text, area, and so on, and critically at the bottom's also stack and Grid to help you build a Layout with the other building blocks.

But the problem was React UI is for the Web and I'm building for React Native.

But it got me thinking, can I just take that and maybe create a React native design system using those primitives, maybe those Layout constructs would help me with the responsive composition of my app.

And so I tried doing exactly that and after a bunch of trial and error, I got something working.

Thought to message Sid said, Hey Sid, how's it going?

Enjoying Amsterdam?

I wanted to reach out to say I'm a big fan of React UI.

In fact, such a big fan ended up implementing large parts of it for React Native in a cross platform manner.

It's a shameless rip of React UI, but of course React UI's for the Web, and what I've done is for React Native.

Thus, no emotion, no CSS, had to implement stack a bit differently and so on.

Sid kindly responded.

That's really cool.

React UI is a ripoff theme UI.

Ripoffs all the way down as I've been known for saying, good artists copy, great artist steal, right?

And so looking at the dates on these messages, you can see this was peak lockdown in 2020 that I was working on this.

And here's an example of what I built back then.

You could see the code on the left and the rendered component on the right.

you can see this by just going to Guild right now.

This is straight code from our production code base and hopefully you can just see what's going on.

you can see by just looking at the code, how it maps with the ui.

The critical construct that makes all of this composable is that stack component.

Where all you need to do is just set the gap property and the rest renders based on that.

I don't need to pass the style prop downward.

I don't have to like manually, configure the styling of each and every single component.

It's highly declarative, highly composable, just based on that stack.

Then at the bottom there, I render a user, user item component, where if I pull up the code for that and highlight the, part of the ui, with that red dotted line, you can see, the code that's powering that.

Again, it's just a, just another stack.

This time the stack is horizontal.

It renders the user's primary photo, renders a link component with the user's name.

By simply composing these stacks, we're able to write an entire UI that glues together very nicely.

I think that's what we call being a full stack developer.

Then we can place all of that within a grid, which you can see here.

Each stack is a row.

we have a grid with columns within each row by, again, simply composing these stacks into a grid.

With columns, we can just build the entire UI in the right, and as you can see, it's fully responsive as well.

So at this point I was, I was pretty happy with what I built.

all of Guild, we built the entire Web application, in this way, the entire cross-platform, react native application in this way.

And so I wanted to, release it.

I came up with a snazzy name.

I thought I'd call it Mondrian.

And of course, if, this is named after the famous Dutch design system engineer, Piet Mondrian, known for composing stacks into UIs that look like this.

I created an empty repo on GitHub, started preparing for a public release cuz I was pretty happy to share Mondrian with all of you.

And that's exactly when I found out about Native Base.

So let's compare Native base with Mondrian, shall we?

All right.

it's an every platform React native design system as well.

It's far more comprehensive than what we've built.

We're at Alpha three, they're at, version three and beyond.

they have accessibility.

They also have documentation and critically they were built in Bangalore, which were the inspiration for Mondrian all along.

And so these days, if I was to use an every platform, react native design system, I would just say go use Native Base.

What they've done is absolutely fantastic and you have a great team over there working on it as well.

But since writing this talk earlier this year, I've had the pleasure of traveling to a lot of communities everywhere and listening to their response to this talk.

Along the way, I came to know of another React native design system called Tamagui.

I'm not, I think it's Tamagui.

I'm not sure it's Tamagotchi.

I don't know what, I dunno what that character is.

but anyway, it's an optimizing compiler for React Native and Web.

So what does that mean?

They provided these examples in their docs, and I understand the text is quite small.

so I'd recommend just going to their documentation website and just looking through the tabs yourself.

It's better than what I'd be able to describe anyway.

But in essence, on the top left, you write your UI using Tamagui's, design system components.

They compile that straight down to platform specific react, on the bottom left.

On the top right, you can configure their whole style system.

however, you like, you can customize everything.

And on the bottom right, they output that into, in this case, Web specific, CSS with full media query, CSS variables and everything else.

it's a fully platform specific compiler where you can write your code in kind of high level design system.

and it will, it'll compile it down to straight platform specific, whatever for whatever platform.

So the culmination of that is, performance, where it renders dramatically faster than React native Web on Web.

As it compiles straight down to platform specific react, it, reduces the amount of, like kind of components you have in your tree.

So like the actual diffing time is faster as well.

and it's incredible on Web.

On native, it compiles down to React native itself.

So it can't be any faster than React native.

but it offers a wealth of functionality beyond what just raw React native offers.

It does things such as Layout stacking, design system tokens, variants, and so on.

And so for being a hair slower than React native itself and offering all those great features, I think that's perfectly acceptable to me.

it looks actually amazing.

Out of the box, they have all the things you'd expect, like a stack that I mentioned earlier in Mondrian.

They also have a text and forms and so on, but they also have this component, a sheet.

And it can be rendered as a modal or inline as I'm showing you here.

But critically, these types of components are difficult to do once to do cross-platform, to do it well, to make it feel native and make sure it's fast.

I really like how Tamagui has done this, like by basically being in the middle of this Venn diagram and I feel like they're the holy grail of, cross-platform, react native everywhere design systems today.

They've done a really good job with it.

Really, I feel like that Scooby-Doo meme where, you write everything using your design system and if you pull off the, the sheet there, it's a Web mobile or native, desktop underneath.

this is how I think of really a cross-platform design system, is you're writing in that high level abstraction and what, what's composing it, underneath, doesn't really matter cuz you're only interfacing essentially with that, spooky ghost character.

Awesome.

So I like what they did so much I tweeted at them, and they tweeted back that they liked the term react native everywhere so much that they borrowed it for the website.

And in fact this tweet they go on to say that Tamagui unlocks about 40% of cross-platform codesharing all by itself.

For me personally, it's just good to see more competitors in this space.

Is good to see the community taking this space seriously.

And I'm just a fan of, more choices.

So really if Tamagui, if so, to go back to our journey, 95 plus percent Codesharing.

If Tamagui is doing the first 40% from the design system, composing that upwards into screens or pages maybe brings us to 60% .The data layer maybe, I don't know, another 80, brings us to 80%.

What's that last little bit to get us to 95 plus percent.

What's, that final thing that we need in order to write those cross platform applications?

it's navigation, of course, right?

We need to navigate through our applications, so let's dive deeper into that.

There's of course internal navigation, like on mobile and desktop, where on these platforms you navigate, internal to the actual UI itself.

You tap a button, you navigate to a new screen.

That's how you navigate on those platforms.

Essentially, the UI is the navigational construct without much else In terms of external navigational controls.

The main, exception is Android's back button, where push a back button.

But, I'll leave, I'll, gloss over that for now.

Then there's external navigation, like what we find on the Web, where the browser has a back button, a forward button, a refresh button, a URL bar, and tabs.

Each of these manipulates the navigational state of the application externally to the application itself.

Obviously, you don't have to explain how a browser works, but the main navigational experience that differs is that is basically the URL bar.

that does not exist, on, mobile or desktop.

And on Web you should be able to copy a URL into a new tab and it should just work, for example.

So to demonstrate that here's a recording from, my Cat's Instagram page of course.

She's just too adorable.

and if we navigate using the ui, a modal open opens contextually to let us know the page we're in, we're initiating that from, you can see us overlaid on the rest of the feed behind it.

Now if I copy that URL into a new tab, it doesn't know what to put behind that modal.

So it just opens that full image as a full new page.

This type of, navigational experience is unique to Web and fundamentally does not exist on mobile or desktop.

So if we were to build a navigational, across platform, every platform, navigational framework, it needs to be able to work across both fundamentally.

So how do we go about doing that?

of course there's React Router, which support, which advertises support for browser-based DOM routing as well as React Native.

And while this does technically work well, it lacks the native bindings on mobile to make it feel properly native.

You can't, kind of slide from the edge of the screen to go backwards, for example.

Like things like that just don't work.

Then there's React navigation, which is a full on mobile first navigational experience.

If you've worked with the React native before, you've likely used React navigation.

It's amazing on, on mobile.

It uses React native screens from Software Mansion to provide that drag from the edge of the screen to go back functionality.

And it's, as I said, amazing.

They provide all of the UI outta the box.

it just works and works very well.

They've had years and years of experience refining this.

it's very well done.

In recent years, they've both shipped Web support as I'm showing here.

And so we tried this, we tried implementing this for Guild, and in my opinion, it just didn't feel right.

It just didn't feel correct.

It technically worked, but it felt heavy and a bunch of things just felt off.

Things like incremental loading of routes, which you want in the Web cause you don't wanna load everything in one gigantic payload.

It just made the URL bar evaluate incrementally as well.

You would just sit there watching the thing just fill in, which looked weird.

Pressing the back and forward buttons repeatedly put the whole app in a weird state and it just couldn't recover from that state.

so you had, you'd hit the refresh button and then the URL bar would then, evaluate incrementally again as well.

It was just -Okay.

And so to summarize, basically, react Router has great state management, but doesn't quite feel native on non Web platforms and React navigation state management is a bit wonky, but has that native feel.

when building a 95 plus percent shared code base, we would just have to go with React navigation.

That's just the best we have right now, despite its flaws on the Web.

The UX won't be ideal, but that's just, users will just have to live with it cuz that's just the best that we have.

And I know the team there is smart, and I know they're working very hard on this.

I tried, lending a hand by sending in pull requests, but it quickly became apparent to me that a library with the heritage of React navigation requires much more than I was able to give.

And we'll just wait, we'll just upgrade as the team upgrades.

And, they're aware of this.

Whenever they make the UX better, we'll just improve whenever we upgrade.

And that's just what it is.

And more recently, however, speaking with the community, again, a lot of people have been asking me about Solito and my thoughts on Solito.

has anyone here used Solito?

I'm just curious.

and so there's been a lot of marketing around this tool solving cross platform navigation.

And my personal view on Solito is that it makes it easier to manage a Web navigation stack powered by Next JS, alongside a separate native navigation stack, powered by React navigation.

You basically have two different navigational stacks, and you can see this in their docs when creating a route.

it requires you to define it on the Web and then also define it on the native side, and you need to additionally tell React navigation how to link that screen to the U R L structure.

So by design, it's not 95 plus percentage codesharing, you're not codesharing, you have two different nav, navigational stacks and you're trying to align the URLs to allow you to navigate within each of those.

if it did share code, it would be one step.

so this is, a fine solution if you want two different navigational stacks then I'll highly recommend it, but it's not codesharing in and of itself.

And during the travels I mentioned earlier, I actually ran into the Expo team.

this is, Brent, who's actually a core maintainer of React navigation, Evan and Charlie, who are on the expo team as well, and I had a great chat with them.

this was back in April at React Miami.

I had such a good chat with them that I sat down with Evan, to hear about his thoughts on the current frontier of every platform, react native.

And so the next day we sat down to talk more about build tooling, navigation, bundling, and so on, and recorded it for our YouTube channel.

You can check it out, at the link I posted down there below for that full interview.

He had amazing ideas back in April and I was so stoked to see it come to fruition six months later where he just recently released expo router.

And this legitimately looks unreal.

I'm so happy to see that this actually came to fruition, after our talk back in April.

So to create a screen, you just create a screen.

It's just one step.

That's it.

it's actually fully shared, navigation across every single platform, and it fundamentally unifies native routing around URLs, which makes it far easier to, easier for you to author your entire navigational stack and, not have to define those linking, constructs once again to tell native how to deep link into your screens.

another nice side effect is that, so therefore you can just deep link on mobile, the same way you would just link everywhere on Web.

And so who would have guesed that URLs would've done it?

Who would have guessed that all, native needed was just a few URLs?

This router's currently in beta at the moment as the Expo team seeking feedback, in order to refine it before an official public release.

And for us, it's just unfortunately still not quite ready.

I'm a big fan of the direction, but it's just not ready for us in production, only because it only supports a metro bundler at the moment.

It doesn't, which, and the metro bundler for Web doesn't support code splitting.

No tree shaking, no CSS handling, no asset manifest, and so on, which are hugely important for building modern Web experiences of course.

All of this is on the team's radar.

This is from the Expo docs themselves.

They're fully aware, they have this all on their roadmap, working with the metro team over at Facebook in order to implement.

but they are a small team and they have a lot on their plate.

Of course.

And so it's gonna take them a while to implement all these awesome features.

I can't wait for them to do it.

I honestly, truly believe this is gonna be the future of, every platform routing, but it's still just, not quite there yet.

So for now, going back to what I said before, if we want truly, a 95% percent plus code sharing across every platform, we're just gonna stick with vanilla react navigation and just wait for Expo router and wait for Metro.

And the users have to deal with that wonkiness for now.

And that's just, the best we have.

And so that's my talk everyone.

Thank you.