Rusting the Gears of React, Part 2: Lessons in Ownership and Composition

Posted by: Diego Navarro (@mrchucu1)

In our first session, we built a static renderer. Today, our goal was to introduce the core abstraction of a UI library: the Component. This journey took an unexpected and valuable turn, forcing us to confront one of Rust’s most important design principles—the Orphan Rule—and culminated in demonstrating the very reason components exist: composition.

From A Data Tree to an Abstraction

Our initial renderer was hardcoded to a specific VDOM tree. This isn’t scalable. The goal is to move towards a declarative API, like React’s, where we can simply say “render the App component” and trust the library to figure out the rest.

To do this in Rust, we first defined a contract for all components using a trait. A trait is like an interface; it specifies that any Component must, at a minimum, know how to render itself into our Virtual DOM Node format.

pub trait Component: Debug {
    fn render(&self) -> Node;
    // ... more to come
}

We encapsulated our UI inside an App struct that implements this trait. The next logical step was to teach our VDOM about this new concept, so we added a new Node variant: Component(...).

The First Hurdle: Making Components Clonable

Our first attempt looked like this: Component(Box<dyn Component>). This uses a Box (a pointer to heap-allocated data) and a dyn Component (a “trait object” that can hold any struct implementing our trait). This worked for the initial render, but we were thinking ahead.

To implement React’s “diffing” algorithm later, we’ll need to hold two VDOM trees in memory: the old one and the new one. This means we must be able to clone our VDOM. When we tried to automatically derive(Clone) on our Node enum, the Rust compiler correctly stopped us. A dyn Component trait object doesn’t have a known size or structure, so the compiler has no idea how to copy it. It can’t be automatically cloned.

A Deeper Lesson from the Compiler: The Orphan Rule

Our journey to solve the Clone problem led us to an even more fundamental concept. Our next idea was to use Rc (a reference-counted smart pointer) and manually implement Clone for it.

// Our attempted (and illegal) code:
impl Clone for Rc<dyn Component> { /* ... */ }

The compiler immediately stopped us with error E0117, enforcing the Orphan Rule. This rule is a cornerstone of Rust’s stability. It states: you can’t implement a foreign trait for a foreign type.

In our case, both the Clone trait and the Rc type come from Rust’s standard library; they are “foreign” to our crate. The orphan rule prevents chaos in the ecosystem by ensuring that any implementation is “owned” by either the trait’s crate or the type’s crate.

The Idiomatic Solution: The “Newtype” Pattern

The solution is a powerful and common Rust pattern. If we can’t implement a trait for a foreign type, we simply wrap that foreign type in a new, local type of our own. This is called a newtype.

We created a simple wrapper struct:

// A "newtype" that wraps the foreign `Rc` type.
// `VComponent` is OUR type, so we can implement traits for it.
#[derive(Clone)]
pub struct VComponent(Rc<dyn Component>);

Because VComponent is local to our crate, we were free to implement Clone for it, satisfying the orphan rule. This experience was a perfect demonstration of Rust’s philosophy: the compiler’s strictness isn’t a hindrance; it’s a guide that pushes us toward better, safer, and more robust designs.

The Payoff: Composition in Action

With our robust and efficient component architecture in place, it was time to prove its value. We created a new, simple component called Greeter whose job is to display a message passed to it via a struct field (our version of “props”).

#[derive(Clone)]
pub struct Greeter {
    pub message: String, // This field acts like a React "prop"
}

impl Component for Greeter {
    fn render(&self) -> Node {
        // Renders an <h2> with the message
        // ...
    }
    // ...
}

This Greeter is a reusable, self-contained piece of UI. The true power was revealed when we modified our main App component to use it. The render method for App now looks like a real UI component: it renders some of its own elements and composes them with instances of other components.

// Inside App's render method...
fn render(&self) -> Node {
    Node::Element(Element {
        // ...
        children: vec![
            Node::Element(/* a static h1 element */),

            // Use the Greeter component!
            Node::Component(VComponent(Rc::new(Greeter {
                message: "This is a composed component...".to_string(),
            }))),

            // Reuse the Greeter component with different data!
            Node::Component(VComponent(Rc::new(Greeter {
                message: "Here is another, demonstrating reusability!".to_string(),
            }))),
        ]
    })
}

When you build and run the example now, you’ll see the output from both the App and the Greeter components rendered to the screen. This is the heart of component-based architecture. We’ve successfully created an abstraction that allows us to build complex UIs from small, independent, and reusable pieces.

This solid foundation of clonable, composable components is exactly what we need for our next and most exciting challenge: state management and reactivity.

Rusting the Gears of React: A “From-Scratch” Journey

Posted by: Diego Navarro (@mrchucu1)

As a Lead Software Engineer at Meta, I spend most of my days working within massive, highly-optimized codebases. But to stay sharp, it’s critical to go back to first principles. I recently tasked myself and a senior engineer with a fascinating challenge: What would it take to rewrite the core of React… in Rust?

This isn’t about creating the next production-ready UI framework. Projects like Dioxus and Yew are already doing incredible work in that space. Instead, this is a pedagogical exercise—a way to deeply understand the mechanics of a modern UI library by building it from the ground up, while leveraging the power and safety of Rust and WebAssembly.

This post documents the first leg of our journey: from a blank slate to rendering our first static UI in a browser, entirely from Rust.

Session 1: The Core Atom - The “Element”

The most fundamental unit in React isn’t the component; it’s the Element. When you write <div />, you aren’t creating a DOM node. You’re calling React.createElement(), which returns a lightweight JavaScript object—a blueprint describing what should be rendered.

Our first task was to model this blueprint in Rust. A plain struct was the obvious choice.

#[derive(Debug, PartialEq)]
pub struct Element {
    pub tag_name: String,
    pub children: Vec<Element>,
}

This is as simple as it gets, but it’s the core concept. It’s a tree-like data structure where an element has a tag (like "div") and can contain other elements.

Session 2: Props, Text, and the Virtual DOM

Our initial struct was too simple. Elements have attributes (id, class), and their children aren’t always other elements—sometimes they’re just text. This led to two key improvements.

1. Props: We introduced a HashMap to represent the key-value pairs of element attributes. This is a natural Rust analog to a JavaScript props object.
2. Text Nodes: A div containing “Hello” needs a way to represent the string "Hello". A Rust enum is the perfect tool for this, allowing a Node in our tree to be either an Element or Text.

This gave us our canonical data structures, our Virtual DOM:

use std::collections::HashMap;

// A Node in our VDOM tree can be one of two things
#[derive(Debug, PartialEq, Clone)]
pub enum Node {
    Element(Element),
    Text(String),
}

// An Element now has props and its children are Nodes
#[derive(Debug, PartialEq, Clone)]
pub struct Element {
    pub tag_name: String,
    pub props: HashMap<String, String>,
    pub children: Vec<Node>,
}

With these, we could represent a complete application structure in memory before ever touching the browser.

Session 3: Bridging the Chasm with WebAssembly

Having an in-memory tree is great, but useless unless it can communicate with the browser. This is where WebAssembly (Wasm) comes in. We used wasm-pack to compile our Rust library into a Wasm binary and generate the necessary JavaScript “glue” code.

This process transforms our Rust library into something that looks and feels like a native npm package. To make it callable, we tagged a Rust function with an attribute: #[wasm_bindgen].

The first version of our TypeScript consumer looked like this, simply proving we could call Rust and get data back:

// examples/basic-render-test/src/main.ts
import init, { create_app_node } from 'rusty-react';

async function run() {
  // Initialize the Wasm module
  await init();

  // Call our exported Rust function!
  const appNode = create_app_node();
  console.log('Virtual DOM node from Rust:', appNode);
}

run();

Session 4: From Virtual to Real - The First Renderer

This was the moment of truth. We had a VDOM tree in Rust and a bridge to JavaScript. Now, we had to write the renderer that would walk our tree and create real browser DOM nodes.

The key was the web-sys crate, which provides raw bindings to all browser Web APIs. This lets you write Rust code that directly calls document.createElement() and parent.appendChild().

Our renderer is a simple recursive Rust function:

fn render_node_to_dom(v_node: &Node, document: &Document, parent: &DomNode) {
    match v_node {
        // Base case: create a text node
        Node::Text(text) => {
            let text_node = document.create_text_node(text);
            parent.append_child(&text_node).unwrap();
        }
        // Recursive step: create an element
        Node::Element(element) => {
            // 1. Create the DOM element (e.g., <div>)
            let dom_element = document.create_element(&element.tag_name).unwrap();

            // 2. Set all its attributes (props)
            for (key, value) in &element.props {
                dom_element.set_attribute(key, value).unwrap();
            }

            // 3. Append the new element to its parent
            parent.append_child(&dom_element).unwrap();

            // 4. Recurse for all children, using the new element as the parent
            for child in &element.children {
                render_node_to_dom(child, document, &dom_element);
            }
        }
    }
}

This is the magic. Rust is walking its own data structure and, step-by-step, building a parallel structure in the browser’s DOM.

The Inevitable Hurdles (The Fun Part)

No project is complete without debugging. We hit three classic integration issues that were fantastic learning moments:

1. Namespace Collision: My own struct Element conflicted with the web_sys::Element. The Rust compiler’s clear error message pointed to the solution: renaming the import with use web_sys::{Element as DomElement}.
2. Vite Security: Vite’s dev server initially blocked our app from fetching the .wasm file because it was outside the project’s root directory. The fix was a simple one-line config change in vite.config.ts to adjust the server.fs.allow list.
3. The unreachable Panic: Our app crashed with a RuntimeError: unreachable. This is the Wasm equivalent of a Rust panic!. Tracing it back, it came from an .expect() call on document.get_element_by_id(). The script was executing before the HTML <div id="root"></div> was on the page! A simple reordering of the <script> tag in our index.html fixed it.

Where We Are and What’s Next

We have a solid foundation: a Rust library that can build a virtual DOM and render it into a real, live browser DOM.

But this is just static rendering. The true magic of React lies in its name: reactivity. Our journey ahead involves tackling the really exciting challenges:

• Components: Abstracting UI into reusable, stateful units.
• State Management: Giving components a memory so they can change over time.
• The Reconciliation Algorithm: This is the big one—the “diffing” engine that compares the old VDOM tree with a new one and generates a minimal list of DOM updates.

It’s been an incredible journey so far. Stepping outside of established frameworks forces you to confront the fundamental problems they solve, and doing it in Rust has been a masterclass in safety, performance, and explicit design.

Stay tuned for Part 2.

FWI if you want to see source code for this project go to the repo.

Welcome to my first Jekyll blog post! This is where I’ll share my thoughts and experiences about learning web development, programming, and anything else that interests me. Stay tuned for more posts in the future!