Write Once, Use Everywhere: React Meets Web Components

Hi everyone, thanks for being here. I'm really excited to share this talk with you. Today, we're going to explore something I find super interesting. What happens when React meets web components? I've been working with React for years. I love the component model, the ecosystem, but also I always felt that something was missing.

React gives us a promise of reusable universal components, yet somehow they only really live inside React apps. So in this talk, I want to unpack that. We'll look at what React claims to be, what it actually is, and how web components may help bridge that gap. So before we jump in, a quick about me. I'm Adar Geva, and I've been working on front end systems for quite a while. I like to focus on where frameworks, tooling, and architecture meets.

Lately, I'm working on my own project called myapp.dev. It's all about making AI output, micro front end, and remote UI feel more natural to build and integrate. I love exploring how different technology fits together, and that's exactly what today's talk is about, bringing React and web component into the same conversation. So let's start with this. React. We all know this tagline, right? The library for web and native user interfaces. It's short, confident, and kind of set big expectations. It claims to power interfaces across web and native, and I love that because it sounds like React's promise is universality.

Build once, render everywhere. But as we'll see, there's a gap between the promise and what we actually get in practice. React really shines where it's come to build and manage components. The idea is super simple. Build small reusable pieces like thumbnails or like button, and then compose them together into something bigger, a page, an app, a full experience. It's that Lego brick mindset we all fell in love with. Each piece is isolated, easy to read and about, and once you start thinking in components, it's really hard to go back.

But wait a minute. We just said React is the library for the web and native interfaces, and it lets us build reusable components, right? So shouldn't that mean we can use those components anywhere? Well, not exactly. That's where things start to get interesting. Here's the fine print. React by itself is a library. It gives you components, but not the full picture. If you actually want to use those components in a real app, you usually need to wrap them inside a full React environment. Next.js, Remix, React Router, something that controls the routing, data fetching, the rendering flow.

So even though React sounds universal, it's really kind of trapped inside its ecosystem. You can't just drop React components into a plain web page, or let's say Angular application. At least it's not that easy. So that got me thinking. If React components are so powerful, but kind of locked inside React, what if there is a way to make those components really work anywhere? Components that don't care if you're in React, Angular, Vue, or no framework at all. That's where Web Components comes in. They're not a framework. They're actually built right into the web platform. Web Components let you define your own HTML elements, completely encapsulated, reusable, and framework agnostic. It's like finally having a true native component model for the web.

Something React kind of promised, but the browser itself actually delivers. And the exciting part, Web Components are no longer that niche, half-supported experiment they used to be. In the last few years, every major framework, React, Angular, Vue, Svelte, and more has added solid support for working with custom elements. So now you can finally share a component between projects, teams, and even frameworks without rewriting them every time. The browser handles the heavy lifting, and all the frameworks finally agree to play nice with it. Let's break down what Web Components are actually made of.

There are three main parts. First, the shadow dome. This is what's given Web Component true encapsulation. Styles and markup inside are isolated from the rest of the page, so nothing leaks in or out by accident. Second, custom elements. These are how you define your own HTML tags with real behavior, like user card or like button. And third, HTML templates. Basically, chunks of markup that stay hidden until you decide to clone and use them. Together, these make Web Components self-contained, reusable, and truly portable, built right into the web itself.

Just like React, Web Components have their own built-in life cycle. When you create a custom element, a constructor will call. A method called connected callback, when it's added to the DOM, disconnected callback when it's removed, and even attribute change when its attribute updates. It's all native, no framework needed. So we get the same component reactivity and control directly on the browser level. Now, just like React, we let React render the UI, and then use that rendered HTML as the template inside a custom element. React does the heavy lifting of describing the UI, and the Web Components become the portable wrapper that ships that UI everywhere.

Instead of writing a template by hand, we let React render the UI, and then use that rendered HTML as the template inside a custom element. In other words, React does the heavy lifting of describing the UI, and the Web Components become the portable wrapper that ships that UI everywhere. That gives us the development ergonomics of React, JSX, States, Hooks, plus the portability and encapsulation of native custom elements.

Now, let's jump into a short demo. We'll walk through the code in small, clear, and step-by-step pieces. We start with the simplest possible Web Component, no React yet. Here, it's just defining a new element, called Hello World. When it's added to the DOM, the browser calls connected callback, and we set its inner HTML. That's it. No build step, no library, just pure browser API. Once we registered it with custom element defined, we can literally drop Hello World anywhere.

Here's the React part of the story. A super simple component called Greeting. It just takes a name prop and renders a friendly message. Nothing fancy. No stat yet, no hooks, just a basic React building block we all know. And here's the magic happens. We're creating a custom element called Greeting element, just like before, but this time, inside connected callback, we're using React create root to mount our Greeting component directly into the element. That means React is now rendering inside a native Web Component. The browser owns the lifecycle, and React just paints into it. Once we define it with custom element defined, we can drop Greeting elements in any HTML page.

The browser owns the lifecycle, and React just paints into it. Once we define it with custom element defined, we can drop Greeting elements in any HTML page. No React app setup, no bundler context, and it just works. This Greeting element doesn't care where it's running. You can drop it inside any Angular app view project, spelt plain HTML. It just works. No React context, no provider tree, no build pipeline dependency, just a custom element that the browser already knows how to handle.

And suddenly, React's UI power becomes truly framework agnostic. So now, we're taking it even one step further, making our Web Component dynamic by adding observe attributes. The browser automatically calls attribute change callback whenever one of those attributes changes. In our case, we're watching the name attribute, and every time it's update, we just call render again. And let's React handle the UI. That means I can now write Greeting element name equals Adar in plain HTML, and React will render with that new name. And of course, we're not limited to just one attribute.

We can pass as many props as we want, numbers, objects, array, even complex callbacks. All of it can flow straight into and out from our React Component. The Web Component just became the bridge that takes whatever data or functions you pass in or out, and lets React handle the rendering and logic on the inside. Our Web Component can accept dynamic data from any framework. For example, in View, you can just bind a prop directly with name equals View prop. In Angular, you can just pass a variable in the Angular syntax. Even in plain HTML, you can just hard code the name attribute. The Web Component acts as a universal bridge.

React handles the rendering internally, but any frameworks or vanilla code can feed it data or even callbacks. That means a single React Component can now work in multiple frameworks without rewriting it at all. Fully portable and reactive.

So, I created an example monorepo with Angular, React, and a View application. Inside the React package, I created two components, Like Button and a Video Player. These are just standard React components with the props, state, and normal JSX. Then on the main app, I import these components and render them to the main page, passing props in and getting callbacks out.

For example, in the Video Player, I'm sending the SRC of the video, the poster image, the height and width, and every time that on play or pause click, I just console to the log. Let's see this page in the browser, and as expected, we can see the Video Player and the Like button showing on the screen. If we open the console, of course, every time that a Like button is clicked, a log is printed, as well as when pressing play and pause. Pretty standard.

Now, I created another entry file called Web Component Main. This TypeScript file will be the entry point to expose a new custom element. Let's start by defining a standard custom element. We're going to import Define Component 1, and in this file, we just want to export a class extending HTML elements and render a standard chunk of string HTML. Pretty standard.

Let's see it in action. So, let's see it in the browser. Three elements showing on the screen. We can see them here in the DOM, each of them including the shadow DOM, and once we're passing an attribute called name, we can see it arrived at the right place in the DOM. If we go here and edit templates, so let's add test for example, the application is re-rendered with the right modifications. That's great.

As we can see, we also tried to render Like button and Video Player here, which actually arrived in the DOM but are not implemented yet, so nothing rendered. The browser natively does not aware what is Like button and Video Player, therefore, nothing got rendered. So, let's go and define these components as a custom element and use our existing React component. So, we go here and create Define Like button, and just like before, we're exposing an array of attributes we want to listen to.

We're creating a shadow DOM, but now inside our render function, we're actually using create root from React DOM client and also import our original Like button component, then we can just render directly the Like button component, a React component, sending the props that we collected from attributes. And as we can see, the component got rendered just like before in the React application. It's reacting correctly to the attributes that we are sending. So for example, the height and the width, the SLC of the video or the Like count for the Like component, and if we're willing to use more complex objects like the callbacks that we used before, we can just get the right element from the DOM and pass it as a property.

As we can see, we're fetching the Like button element. It's a web component element and passing unlike change callback and console logo. Let's see. Now, when we're clicking the Like button, the callback from React actually triggers the prop that we passed from a native JavaScript application.

Let's now use these components that exported as custom elements in a Vue app. So I'm going to the Vue application and in our main typesheet file, importing the same WC main that defines the custom elements. And now inside my app, Vue templates, using the Vue player and Like button in a Vue.js syntax. Let's run it and see. And as we can see, the React component is now rendering directly in the Vue context. Looks exactly like we wanted.

All right, let's recap what we've done here. First, the fundamentals. Lifecycle hooks give us control over initialization and cleanup, making components robust. Shadow DOM and scope styles prevent stylized leakage, so our components look consistent no matter where it's used. Next, cross-framework compatibility. This component works seamlessly in React, Angular, Vue, or even plain HTML. Props and events let us communicate clearly between the web component and the host application. And finally, building tool integration, so we can use any bundling approach in both sites. And we basically combine the development ergonomics of React with the portability and encapsulation of native web components. It all works everywhere.