Wait, You're Shipping React Native to the Web?!

Rate this content
Bookmark

This talk focuses on building a production-grade consumer social application - https://guild.host . If you visit that site, would you be able to tell it's built using React Native just by looking and using it?

At a high level, Taz talks about what makes that possible and how the audience should consider application architecture.

At a lower level, Taz focuses on:
- How React's component composition model makes accommodating multiple platforms easy
- How large applications should use a Design System, and the Tamagui Design System comes with an optimizing compiler that outputs straight platform-specific code while the developer still writes high-level UI that happens to utilize React Native's components
- How to Server-Side Render a React Native Web application, and what considerations Guild made when choosing to create a custom SSR engine on top of Cloudflare Workers
- In order for Guild to exist anywhere, they need to embed themselves into other experiences. This involves Third-Party React Native on the Web and other platforms
- The future of this architecture, where Third-Party UI is the same as First-Party UI

32 min
15 Nov, 2023

Video Summary and Transcription

Guild is a platform that needs to exist on all platforms, using React Native to orchestrate them. React Native and Expo provide components that work across platforms. Building applications with React Native involves composing components and using a design system. Choosing the right server-side rendering solution is important for unifying mobile and web codebases. Embedding React Native allows for optimization and embedding in any application. Bridging the gap between UI and API with embeddable experiences is key to supporting communities on every platform.

Available in Español

1. Introduction to React Native on the Web

Short description:

Guild is a platform for communities that exist in all shapes and sizes. We need to build an application that can exist on all platforms. We focus on the web platform in English to manage support overhead. React is the superset of all platforms, and React Native orchestrates them to work together.

Hey, everyone. I'm Taz Singh and over here is Marc Delgliche, and I had the pleasure of chatting with him down in Australia where this photo was taken right after he said, wait, you're using React Native on the web. Why in the world would you do that? And so, if you don't know Marc, he's the creator of CSS modules, vanilla extract, and more recently he's worked on React Native design systems over at Rainbow. Today, he's doing awesome work at the Remix team over at Shopify, and this is the answer I gave to him back then.

I said, well, Marc, this is why. Guild is the platform for communities, and communities are everywhere. They exist in all shapes and sizes, and we need to build an application that is also everywhere and can exist in whatever shapes and size these communities come in on all of the different platforms our users are on today. And so, today when you're building a modern application, you need to cater to both mobile and desktop anyway. So, looking at the usage metrics for Guild, 51% of our users are on mobile devices, and 49% are in desktop. This makes sense because people are interacting with our platform on the go, they're looking for events to attend and presentations to watch, and all of that happens, you know, primarily on a mobile device.

On top of that, we're an early-stage startup with a small team. We need every member of our team to be as effective as possible when shipping code. Every change to our codebase needs to have the highest impact possible. However, if we were to ship code to every platform, we'd also need to support and test all of them. So we'd need to test against every single web browser, we'd need to test every single mobile operating system, and it's the same story on desktop as well. We'd need a bunch of physical devices to test this all on, all from low-end Android devices to Linux boxes to everything out there basically. You can imagine additionally supporting multiple languages, for example, English and Spanish, where the number of items to test and support would start to increase exponentially, and it would just become infeasible for a small team like ours. This is why today we're focusing on the web platform in the English language at the moment. Just to support, keep the support overhead manageable for our small team.

And that's because the way I see it working is a bit like this, where this is the web platform that we're building for today. Once we introduce iOS and Android applications, we can see it looking a bit more like this, where maybe there's a common area in the middle, and as we continue to layer on more platforms like MacOS, Windows, and Linux Native apps, you can see the diagram looking a bit more like this. And for me, this is really where the power of leveraging React comes in handy. Where I see React being the superset of all these platforms, and React Native can encapsulate the logic and orchestration for all of them to work together. So let's focus on React, shall we? What do I mean by that? Well, let's say I have an app in React that looks like this. It renders some component, right? Maybe you start to pass some data into that component, and you get some data out of that component. That's the contract that your application cares about. That underlying component could be doing anything. That underlying component could be using React Native. It could be using a React Native view and rendering to a React Native text element. That underlying component could be using HTML elements, using in a way that's familiar to you if you're using React DOM today on the web.

2. React Native and Expo Components

Short description:

React Native and Expo make it easy to write common code and override with platform-specific code. The Expo SDK has components like blur view, Expo AV for audio/video, and Expo GL View for Open GL rendering. These components work across non-Expo React Native and web applications. React Native follows React's component composition model.

Or it could be using some sort of native view that's entirely platform-specific, in this case an iOS native view that's actually dropping down to some sort of iOS native rendering logic itself. Fundamentally, React Native, and in our case Expo, makes it easy to write the common code on the left, and then override that with something more platform-specific towards the right, just by the file naming convention.

You can see I'm suffixing it with .web.js and .iOS.js to kind of specify one for the web, and one for iOS, and it will fall back of course to the more generalized .js version for other platforms, such as in this case Android or so on and so forth. For us, we always start with the common approach on the left provided by Expo, and then when we need to provide something more platform-specific we'll then override it with the appropriate file extension as I've described here. Because remember, the contract remains the same. It's just a React component that's passing data in and getting data out.

The composability of this model is what really makes all of it possible, and for me, it never feels like I'm giving anything up. It never feels like I'm being let down. It never feels like I'm being run around and deserted. Thankfully, the Expo SDK has most of what you need to make all of these things work. Just looking at a few of their examples from their docs, we can see they have a blur view. They go so far as to list platform compatibility for this right inside their docs itself. So we can see it's supported on the web as well as iOS. But then what do we do for Android? Thankfully, a quick Google search led me to this library, React Native Community Blur, which provides the same functionality for Android. Again, just by naming these files specifically for each platform, we can create an experience that works everywhere with a common API that works across both.

Expo has a bunch of other components and APIs that you can leverage when building a cross-platform application. One of them is Expo AV for displaying audio or video. Again, they have a helpful list of platforms that it's all compatible with. Expo GL View, if you're rendering Open GL, this is, again, compatible across every single platform. On the web, it renders to WebGL, and fundamentally, you can go look at the docs for yourself on the Expo page. They have something for just about everything out there. The lovely thing is that all of these components technically work across any non-Expo React Native application, and they also technically work across any non-Expo web application. However, I haven't actually tried those combinations myself, so I can't speak to my own personal experience from them. I just know that it's all technically possible, so if you want to experiment, you know, go ahead and feel free to let me know how it works out for you. All of this works because components are the building blocks of React Native. We think of components first, and we compose these components in order to make applications. If you want to blur something, you just compose in a blur view instead of thinking about the particular CSS properties to achieve something similar. If you want to display a video, you just compose in the Xboav library and use their video component right then and there. If you want to display some graphics, you can just do the same thing with the Xbogl component. Fundamentally, React Native is true to React's core model of component composition.

3. Building Applications with React Native

Short description:

Instead of worrying about platform specificities, we simply compose these components and let those underlying components do all the heavy lifting for us. If I were to start today, what I'd recommend is Tomagui for the design system. The optimizing compiler for React Native applications creates straight platform-specific code for your application. Any serious application should be using a design system and Tamagui is an excellent one. To stitch it all together, I'd recommend checking out React Native URL router for navigation.

Instead of worrying about platform specificities, we simply compose these components and let those underlying components do all the heavy lifting for us. We just care about that top level contract, and that's really what React is all about. Cool.

So, that's basically how we develop using the underlying React Native component system. As you can see, that's everything we need and we don't feel left out because we can always drop down to something more platform specific and compose components in a manner that's true to React.

But how do we build an application out of this? Well, I'd recommend checking out a presentation I gave last year called React Native Everywhere. You can find that by heading over to my profile and Gil, just link there in the top left and check out the presentations I've given. I go into more detail about how I think about React Native design systems and also navigation within cross-platform React Native as well.

But in essence, if I were to start today, what I'd recommend is Tomagui for the design system. We've actually started migrating over to this and we're seeing amazing results, I highly recommend checking it out. It's styling and optimizing compiler and UI kit that unifies React Native and the web. It sounds amazing. I had the pleasure of hanging out with Nate Vinehart earlier this year where we chatted about Tomagui on camera, which will be up on my profile as well when we get around to releasing that. So check that out for a deeper dive essentially with Nate.

In essence, however, the optimizing compiler for React Native applications creates straight platform-specific code for your application. This screenshot shows how we take generic React Native code on the left written, of course, in the Tomagui design system. And on the right, it compiles down straight to the web platform itself. So just looking at the code on the left for a minute and feel free to pause the video if you want to take a look at it a bit more, it's just using a stack component for layout and a heading component for text. That's the code you write, and that's all you need to think about when you're creating UIs. Just the top level of kind of how it works. It's highly declarative and you don't need to worry about what's below because of React's component composition model. If I was to zoom into that compiled output, however, it essentially looks like what you'd write if you were writing highly optimized platform-specific code using React DOM and CSS variables for everything. The semantic HTML has compiled down to a div with an H1 tag in React and the CSS uses all of the appropriate media queries to make it all work just as you'd expect if you were to handwrite this all from scratch yourself. This works obviously extremely well on the web, because you can then use those higher level components to compose your application and let the tooling worry about how to create something better suited for the specificities of that platform. Any serious application should, of course, be using a design system and Tamagui is an excellent one.

To stitch it all together, I'd recommend checking out React Native URL router for navigation. It's essentially React router with all of its state management goodness, plus React Native screens to give it that native swipe from the edge feeling that you're used to when using a native mobile app. As we're currently building for the web right now, we're actually just using React router directly at the moment. However, we're planning on using React Native URL router when we do expand to mobile platforms as well. You can kind of think of React Native URL router as a layer on top of React router.

4. Choosing the Right Server-Side Rendering Solution

Short description:

They're both incredibly compatible. We need server-side rendering for React Native. Next.js and Remix are fantastic options, but they don't provide a unified codebase for mobile and web. We want to unify our navigation stack. I spoke with Evan Bacon from the Expo team about this.

So, they're both incredibly compatible. So, what we're doing is really a stepping stone towards that mobile future. And since we're rendering for the web, we need one key feature that you may not need if you're not rendering for the web, and that's server side rendering, of course. But for React Native, because we're building a consumer application, I mean, of course we want server side rendering. It's of great importance for us from an SEO perspective as well as performance perspective just to provide that experience immediately when a user lands on our page.

But how do we do this for React Native? Well, I'm sure when I say this, a lot of you think of Next.js. You'd be right. They have a fantastic server side rendering pipeline, and they spent a lot of time optimizing it, and it's really state of the art. It's one of the best out there. But I don't quite think this framework is right for us. And the reason for that is if we were to use Next, we'd have to build on top of their router. And while that in and of itself is fine, it doesn't really provide us a path forward for mobile as well. Sure, we could build out a whole separate navigation stack just for mobile and run that concurrently with a web navigational stack. And we have two entirely differently navigational stacks in our application. But that wouldn't really help us unify our code across platforms. And fundamentally, it would just create more work for the team as well as creating more potential areas of inconsistency, because I mean, it's just fundamentally two different things. And so I don't quite think Next is a fit for us for that reason.

Of course, there's also Remix, which has a great server side rendering engine built directly into it. Right now I say our stack is most aligned with Remix as we're currently using React router, which also powers Remix. However, again, they don't support React native URL router. And so moving forward with Remix would mean that we need to do something different there once again. Perhaps it would be less intrusive than Next because we're currently a bit more compatible with the Remix approach. And technically, they're both fantastic options maybe for you. If you have a similar set of concerns, that's why I'm mentioning these, because they are truly fantastic world class options out there. But for us, it's just the way that we think about this in that we do want to unify our navigation and have one navigational stack across everything. And fundamentally, both of these aren't really solutions for us. But maybe these are solutions for you.

Now, fundamentally, what do we do though? Essentially, what works for us? Well, thankfully, I had the pleasure of sitting down with Evan Bacon from the Expo team to chat about this. You can see the recording of that following the link on the top left or just heading to my profile or just heading on Guild and searching Google as well. Overall, Evan is an amazing dude.

5. Expo Router and Building it Ourselves

Short description:

He's one of those brilliant minds out there and he has such unique insights on this space that it was such a blast sitting down and talking to him about the future of navigation and bundling from an every platform perspective within React Native. About six months after this conversation, Evan came out with Expo Router. However, it's just not quite there today. They don't have active server-side rendering or other web-specific features such as code splitting just yet. I am a little skeptical however, because they are using React Navigation on the web platform. But fundamentally, what do we do today? Well, I guess, fundamentally, we'll just have to build it today. We'll just build it ourselves. And so we rolled up our sleeves and we built an entire server side rendering pipeline on top of Cloudflare workers to power Guilds Web Experience.

He's one of those brilliant minds out there and he has such unique insights on this space that it was such a blast sitting down and talking to him about the future of navigation and bundling from an every platform perspective within React Native.

About six months after this conversation, Evan came out with Expo Router. Conceptually, I believe this to be the most future-facing solution that works with the majority of how we build our app. It's quite literally been built with cross-platform navigation in mind and it was kind of spawned from that conversation I had with Evan so obviously I feel quite good about the solution.

However, it's just not quite there today. They don't have active server-side rendering or other web-specific features such as code splitting just yet. With Expo Router v2, you can render your React Native web apps to static files and serve static files if that works for your app. But for us, we do need active server-side rendering as we do have dynamic data that we do want to be rendered on the server.

Evan mentioned that this is coming and he envisions the Expo Router project to be about two quarters of its way to completion based on their current iteration today. So there's two more quarters left to really fulfill his vision and one of those active server-side rendering and code splitting and etc will be a part of it. And so we'll definitely keep an eye on that and maybe we'll look to migrate when that comes out.

I am a little skeptical however, because they are using React Navigation on the web platform. I have a feeling that because React Navigation ships UI as well as routing, it would result in a larger bundle. Every project I've ever worked on I've kind of overwritten React Navigation's default UI. So I'd prefer if those two were maybe decoupled. However again, the team there is smart, they're brilliant, they're good friends of mine and I know they're working hard on this stuff. They take it very seriously and they listen to feedback. And so that's kind of everything you could ever wish for in terms of a technology provider. And so these are all things that they know and I'm sure they'll execute well on this in time when they hit those other two milestones and get it to a four out of four in terms of completion. So we'll definitely keep an eye on this and maybe we'll look to move over in the future.

But fundamentally, what do we do today? Well, I guess, fundamentally, we'll just have to build it today. We'll just build it ourselves. And so we rolled up our sleeves and we built an entire server side rendering pipeline on top of Cloudflare workers to power Guilds Web Experience. It utilizes all of the latest React 18 concurrent rendering in terms of streaming responses over to the user. Cloudflare also informs us of the user's device type, which we then use to server side render into the breakpoint that that person is likely to get. So, for example, if it's a mobile device, we'll render into a mobile breakpoint. If it's a desktop device, we'll render into a desktop breakpoint and so on, directly from the server itself. And this is because React Native uses the Window Dimensions API and not media queries, unless you're using something like Tamagooie. But even rendering into a breakpoint on Tamagooie, you need something similar to kind of tell you what device type to render into. So it's great that Cloudflare provides all that.

6. Optimizing and Embedding React Native

Short description:

Because we built it ourselves, we can optimize it. We know all the pieces of the framework. We embed relay store into the initial payload to avoid refetching. React Native is truly native and can be stitched into any application. We created GIL's embeddable SDK using React Native on the web and Relay. It's not using iframes and allows native embedding.

And because we built it ourselves, we can actually make that optimization ourselves because we essentially know the pieces of the framework that we're working with. But if you were to do this on something like Next.js or Remix or something like that that doesn't support all of this and doesn't really know how to make that, like, essentially glue those bits together, you may not have such a good experience. And so we're able to do so because we know all those pieces together.

Additionally, because we're using a relay for our data fetching over GraphQL, we're able to embed all of that initial data over that initial payload to avoid refetching on initial load. So we just embed the relay store directly into the initial payload. So when you first load the page, everything's just there, no additional data calls, no loading spinners, and that's it. So feel free to give it a go. Load up gil.host yourself and just see what it loads like. No loading spinners, should load immediately and should work great.

And fundamentally, the reason why any of this even works is because it's native. React Native is native. It's not React Mobile. It's not React Web. It's React Native because it's truly able to address the native platform on any platform. On the web, it's really just like any other web application. Therefore, you can server side render a React Native web application the same way you can server side render any other React Web application. You can use Next, you can use Remix. You can use whatever you want. It's just like rendering any other React application. Because, fundamentally, you're just rendering the same thing all over again.

All of this got me thinking, though. If React Native is truly native, can I stitch React Native into any application, regardless of how it's built? I mean, Facebook's mobile app is technically just React Native stitched into other native views, right? That's kind of how the entire Facebook application works. It's just React Native next to native. If they can do that with this technology, I mean, surely it's possible for any of us to do as well, right? So, for me, I tried doing exactly that. I tried doing that for GIL's embeddable SDK, where we basically taken all of the building blocks of our UI, created using React Native on the web, and powered by Relay for declarative isolated data dependencies, and taken all of that and provided it as a JavaScript library for folks to natively embed into any page. It's not using iframes, because the challenge with iframes is you can't really operate outside of the frame, so you can't open a modal with more information, for example. As you can see in this public code sandbox, which you can check out for yourself by heading to the link up there at the very top of the page, the mxcfmh link, the HTML is rendering a list of div tags with IDs. That's what I specified in the HTML code sandbox. At the bottom, we're loading the GIL JavaScript SDK into the page, and providing it with all the different elements to render into with the various arguments from our SDK, and the GIL SDK is simply rendering the rest. With this approach, you can take the exact same components that we use to build GILD, and you can natively render that within your experience however which way you want.

7. Embedding React Native Everywhere

Short description:

You can embed our event and presentation components into your website, recreating our entire UI. With our React Native embeddable strategy, we can exist everywhere. In the past, I've embedded React Native directly into Flutter, proving the technical capability of embedding React Native into any application.

You can embed our event component directly into your conference's website and do ticketing through GILD. You can embed our presentation component directly into your personal website, and have all the history of all the different presentations you've ever given with a link back to GILD for more on your profile. Fundamentally you can recreate our entire UI if you wanted to, giving you an easy path forward to deeply and easily integrate into any workflow that you have for your community.

And this is what I mean when I say communities are everywhere. They exist in all shapes and sizes, and we have to be there as well. With our React Native embeddable strategy, we can truly exist everywhere.

Now I know what you're thinking. Wait. But this is for the web, right? I mean, this isn't really truly everywhere if it's not really on other platforms as well. I mean, yeah, you'd actually technically be correct. Right now we are only developing for web platforms. However, this is not my first Rodeo embedding React Native on other platforms. And I'm actually not sure if I'm allowed to say this. Let me just message the organizers real quick. One sec. Sorry. Um, hey, am I allowed to say the F word on camera? Sorry, they're just typing back to me right now. No, I'm not allowed to say that on camera. That's a bit awkward. Well, I'm saying it anyway. Flutter. That's right, folks. In the past, I've embedded React Native directly into Flutter. I was consulting for a large Fortune 100 company where one team chose to use Flutter and another team chose to use React Native. However, the business wanted one consumer-facing application. So, either the Flutter team had to recreate everything the React Native team was doing, or vice versa, or we could seek to embed one inside the other. And I took that as a challenge. For me, I knew that if we could stitch React Native into Flutter, then I knew that truly anything is possible because the technical capability of embedding React Native into any application would be truly proven. Because, like me, I'm sure in even just saying this, I'm sure a bunch of you are skeptical. Because Flutter renders very differently than React Native.

8. Embedding React Native into Flutter

Short description:

Flutter renders to a canvas, while React Native renders a full tree of native views. We can embed React Native into Flutter by taking screenshots of the native view and compositing it into the Flutter canvas. This allows us to use native components within Flutter and integrate React Native deeply. React Native is native and respects the platform it's built on, acting as an orchestration layer. By using React Native, we gain the power of the React Native ecosystem.

Flutter essentially renders to a canvas, and so we can see that in the top screen shot, where it's just kind of rendering to one view. This is basically a hierarchy, a 3D hierarchy of the different views. And you can see in the top screen shot, it's a very thin hierarchy because it's basically just a single canvas, rendering an equivalent UI across both. React Native renders a full tree of native views, which we can see on the bottom. You can see that there's several views stacked on top of each other in terms of that 3D view hierarchy there.

So, to be clear here, I'm not criticizing one approach over the other. They're both just different ways of building applications with different benefits. But this is fundamentally how the two render. The both of them render quite differently. And for me, it just fundamentally got me thinking, can we actually embed React Native into Flutter? Can we take our same React Native components and truly put that on any platform regardless of how it's built? How native is React Native really? Well, it turns out, yeah. We can actually embed native views into Flutter. Under the hood, Flutter basically takes screenshots of that native view rendered on a separate thread and then composits that into the Flutter canvas. This does come with a performance hit inside Flutter, as you're no longer rendering inside Flutter's highly optimized canvas, but this method does technically exist. And it makes sense, because it's not really entirely feasible for Flutter to do everything within their system. Maps, for example. You want to be a native map that the user chooses, you wouldn't want to really recreate a whole Maps component inside Flutter. You want to bring in that native Maps component and you want that to be stitched inside Flutter. So taking that and combining that with the ability to stitch iOS views, or take iOS views out of React Native and kind of stitch that into any platform, pulling that into Flutter, we were able to embed React Native directly into Flutter itself. In the past, our example of this was able to integrate so deeply that it was actually indecipherable to both the user and the developer. For the developer, they were able to feed props directly into React from Flutter State Management System and were able to pass information back up through React handlers directly back into Flutter State Management System. It was so native, it was even native to developers. All of this is possible again because React Native is native. It respects the platform it's building on top of. I see it more as an orchestration layer that enables you to opt into the JavaScript ecosystem of tools and manage your native application more agnostically. By using React Native, I don't feel like we're losing out on anything that we didn't have before. Quite the opposite. I feel like we're gaining a super power of opting into the React Native ecosystem to enable all the things that we're doing.

Now, I spent a lot of time talking about the why and how of our process. Let me take a moment to show you what we've built. This is the Guild homepage built entirely using React Native on the web.

9. React Native Navigation and UI/API Gap

Short description:

Our navigation system is done using React Native reanimated and Expo GL. The avatars and animations are also created with React Native. The entire page is built using React Native on the web platform, with one platform-specific override. We have a UI and an API as mechanisms for using Guild, but there's a big gap between the two modes.

Our navigation system transforms around user input. That animation is done using React Native reanimated. This subtle effect is done using Expo GL, which is rendered to WebGL on the web platform. Again, it's fully cross-platform compatible. You can kind of see that wave moving in the background. That's all done via Expo GL. Let's just take a moment to watch it, then, shall we?

Okay, there we go. This animation is, again, done using reanimated. All these components are actual React Native components. We can interact with them and open a React Native modal here, for example. So that's just a modal in React Native. These avatars down here, oh, when we get up to them, I guess, all these avatars there, they're all created using mid journey AI, and we use mid journey to create the virtual avatars for each user as well. So it's mid journey on top of mid journey and the animation is, of course, done with React Native reanimated. These presentation cards are using the Satori library, which uses React Native's yoga layout system running on a web assembly inside a CloudFlare worker to render an SVG. So even these images, even these image cards are actually rendered using React Native. And then scrolling down a little bit, there we go. This network's animation over here is the only web-specific thing on the entire page. We could have used React Native Skia, but at the time that we built this, the bundle size for that was about six megabytes on the web, which was just too large for this. Since then, William Candillon, if I'm pronouncing his name properly, has reduced it to about 20 kilobytes. So we can actually reuse React Native Skia on there right now. And this again is a React Native modal, a native React Native modal. This entire page is built using React Native on the web platform with one little platform-specific override for that networks and guilds presentation. But again, we can now rewrite that using React Native as well because William's done such a great job on the Skia project to reduce the bundle size to about 20 kilobytes for that. So fantastic stuff by that team.

However, I need to ask you, looking at this, would you have been able to tell that any of that was React Native or would you just think that all of that was just some other web app built in a more traditional way? So, fundamentally, what does this mean? The way we think about it is that we have our UI and we have our API. Both exist as mechanisms of using Guild. Users can go to our UI on our platform and manage their community. Or they can register for our API, manage their secrets, figure out the queries they need, perform their mutations and build a whole UI themselves. And this may be fine if you want a custom experience and you have the resources to support all of that API development. But there's fundamentally a big gap there between using those two modes.

10. Bridging the Gap with Embeddable Experiences

Short description:

There's a big gap between using our first party UI and using our API to build everything yourself. We can bridge that gap with embeddable experiences, allowing any part of our UI to be placed where the traffic exists. By leveraging embeddable experiences, third-party UI can be as easy to use as mounting a React component. We aim to improve the process of exposing these third-party experiences and make it easy for everyone. Supporting communities on every platform is critical to our business, and we look forward to sharing more about our journey and open sourcing our work.

There's a big gap between using our first party UI and using our API to build everything yourself. What if we can bridge that gap with embeddable experiences where you can take any part of our UI and place that where the traffic exists regardless of platform? What if React Summit wanted to use Guild for registration and put that directly into their platform? They can take the attend button and put that directly on the React Summit website itself. By taking that experience and placing it where the traffic exists, they're able to leverage our UI and essentially get a fast path towards implementation wherever they need it.

This got me thinking, what if we took embeddable experiences seriously? What if we built our apps in a way that third-party UI was the same as first-party UI? What would that look like? Well, right now we have all the various parts of our app built inside our design system as individual components that compose together. I'm sure a lot of you do this as well, because fundamentally that's how React works. If you're using Storybook, you likely export all of these components already, right? So then, taking a look at those building blocks and exporting those as embeddable experiences, we can just render our UI out of that. And again, this is just how you'd use React right now. But the gap that we found is making that embeddable. We had to write custom logic to essentially contain all of these experiences to work inside other experiences. Let me turn that light off. That's the part that we need to work on improving, so that exposing these third party experiences becomes as easy as mounting a React component.

Furthermore, right now, we have to aggressively code split our SDK to only load the JavaScript required when you use it. But what if we can leverage Island-based hydration to only load the parts that are truly interactive, thus bringing down the web bundle even further? What would that look like in an embeddable world? And how can we make that easy for everyone? So for us at Guild, this is our next frontier. It's critical to our business to support communities everywhere in whatever shape and size they come in on every platform they're on. We need to exist where the traffic exists. And that's what I told Mark back in Australia. I look forward to coming back and telling you more about our journey as we work towards finalizing this and open sourcing our work to make it easy for anyone to use our infrastructure, because all of this has worked so well for us. And I can't wait for that. Until then, thank you, and I hope you enjoyed our journey.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn