DEV Community: Carlo Straccialini

React vs. Our Fine-Grained Runtime: Two Different Rendering Models

Carlo Straccialini — Thu, 01 Oct 2026 12:31:09 +0000

Before continuing our series on fine-grained reactivity, let's take a closer look at how our approach differs from React's.

This is not a general comparison of the two technologies. We will focus on one question: what happens between a state change and a DOM update? Features such as routing, data fetching, server rendering, and the wider ecosystem are outside the scope of this article.

How React Updates the UI

React is a library for building user interfaces from components. A component combines rendering logic with markup and can hold state that changes over time.

Here is a simple counter:

import { useState } from 'react'

export default function ButtonCounter() {
  const [count, setCount] = useState(0)

  const handleClick = () => setCount((current) => current + 1)

  return (
    <>
      <button onClick={handleClick}>Add 1</button>
      <p>Count: {count}</p>
    </>
  )
}

Two foundational React concepts appear in this example:

JSX is a JavaScript syntax extension that lets us write HTML-like markup inside a component.
State lets a component retain data between renders. Calling the setCount function queues another render with the new value.

Assigning directly to count would neither persist the change nor notify React. State must be updated through its setter.

Render and Commit

React describes a screen update in three steps: trigger, render, and commit. In our example, the flow looks like this:

React performs the initial render by calling ButtonCounter to determine what should appear on screen.
React commits the result by creating the required DOM nodes.
When the user clicks the button, setCount queues another render.
React calls ButtonCounter again and calculates what has changed since the previous render.
During the commit phase, React applies only the necessary DOM operations—in this case, updating the text inside the paragraph.

The important distinction is that the render phase calculates what the UI should look like, while the commit phase applies the required changes to the DOM. React's Render and Commit guide explains this process in more detail.

Rendering a component does not necessarily mean changing the DOM. Consider this variation:

import { useState } from 'react'

export default function ButtonCounter() {
  const [, setCount] = useState(0)

  const handleClick = () => setCount((current) => current + 1)

  return <button onClick={handleClick}>Add 1</button>
}

The state still changes after every click, so React renders the component again. However, the returned JSX does not depend on that state. React finds no change that needs to be committed, so it leaves the DOM untouched.

React has several ways to avoid unnecessary work, and its implementation is considerably more sophisticated than this short overview. The key point for this comparison is its default update model: a state update triggers rendering so React can determine whether the UI must change.

How Our Runtime Differs

Our approach moves much of that discovery work to build time. The compiler analyzes each template, identifies its dynamic expressions, and generates the exact DOM operations needed to update them.

For a template like this:

<p>Hello {{ name }}!</p>

the generated update function already knows that a change to name affects one specific text node:

update(change) {
    if ('name' in change) {
        textNode.data = 'Hello ' + change.name + '!';
    }
}

At runtime, our reactive layer connects a state mutation to this generated function. It does not need to re-execute the whole component or compare two representations of its output to discover which DOM operation is required; the compiler has already established that relationship.

The two models can be summarized like this:

React	Our fine-grained runtime
A state update queues a render	A state mutation identifies its dependants
Rendering calculates the changes required	The compiler generates the relevant update operation at build time
The commit phase applies the necessary DOM operations	The runtime calls the generated DOM operation directly

This approach can reduce runtime work because it does not need to re-execute component render functions and reconcile their latest output to discover DOM changes. The trade-off is that our compiler and runtime must correctly handle dependency tracking, nested data, control flow, lifecycle behavior, and every template feature we support. React solves a much broader and more general problem.

Conclusion

This comparison is not an argument that React is bad or that nobody should use it. React has a mature ecosystem, a capable team and community, and years of production experience behind it. Its rendering model also enables features and scheduling strategies that are beyond the scope of this article.

Our constraints led us to make a different trade-off: analyze legacy templates ahead of time, build a dependency graph, and update only the DOM nodes affected by a mutation. That design helps us modernize a large Angular.js codebase without rewriting all of its templates and controllers.

As described in the first article in this series, this work is inspired mainly by Solid's fine-grained reactivity and Svelte's compiler-based approach.

In the next article, I will explain why we chose this architecture and which constraints made it a good fit for our company.

From Angular.js to Fine-Grained Reactivity: Part 3 - How to Optimize the Render Phase

Carlo Straccialini — Mon, 24 Aug 2026 10:00:00 +0000

In the last article of this series, we saw how to use the Proxy API to notify changes to the templates. For example, this controller:

// simple-controller.js
export function SimpleController($scope) {
    $scope.name = "Mario";
}

produces a change like this:

let changes = {
    name: "Mario",
};

update(changes);

Suppose now that we have a controller with multiple assignments:

// simple-controller.js
export function SimpleController($scope) {
    $scope.name = "Mario";
    $scope.age = 24;
}

This snippet triggers multiple update calls because each individual assignment produces a new change:

let changes = {
    name: "Mario",
};

update(changes);

changes = {
    age: 24,
};

update(changes);

In a real-world controller, there are many more scope assignments than we've seen in this simple example. If we consider a real enterprise app, we could have dozens of controller executions, with multiple assignments for each of them.

Another common problem we might encounter is multiple assignments to the same property; this can lead to a flickering effect on the rendered view.

// simple-controller.js
export function SimpleController($scope) {
    $scope.name = "Mario";

    // Age computation can last up to 100ms
    const age = computeAge();

    $scope.name = `${$scope.name} ${age}`;
}

Let me explain how it works.

The first assignment $scope.name = "Mario" produces a change that immediately calls the update function from the template, so the view is updated. For a fraction of a second, the current user sees the string "Mario" on the screen.

After some time, due to the computation time of the age variable, the second assignment $scope.name = \${$scope.name}${age}; is executed. This second call to the same update function causes a redraw of the browser window so the user can finally see "Mario 24" (assuming the result of computeAge() is 24).

Depending on that computation time, the user might actually see this visual flickering, making it a real risk for the user experience.

Solution: Queueing Mutations via Microtasks

An elegant solution to this problem comes from the event loop and the microtask queue.

I'm sure that many of you are familiar with concepts like Promises, setTimeout, setInterval, and async JavaScript in general. And obviously, you also know the "magic" event loop and how it works. But microtasks? What are they?

A microtask is a function that runs after the calling function has returned, but before the event loop moves to the next tick and checks its macrotask queue. In particular, in a browser environment, it runs before the view is updated with the new values.

To learn more about microtasks, you can study this article on the MDN docs.

To solve the problem of multiple mutations, we can simply merge all the changes before calling the update function. In the next section, you can see a simple implementation of these two concepts.

Building the Batching Engine

let pendingChanges = {};
let isScheduled = false;

function scheduleUpdate(change, updateFn) {
    // Merge changes (overwriting previous values for the same key -> solves flickering!)
    Object.assign(pendingChanges, change);

    if (!isScheduled) {
        isScheduled = true;
        queueMicrotask(() => {
            updateFn(pendingChanges);
            pendingChanges = {};
            isScheduled = false;
        });
    }
}

Our proxies must now call this new scheduleUpdate method instead of calling the update function directly when they intercept a set operation.

Object.assign solves the problem of multiple mutations to the same key because it always overwrites the global pendingChanges object with the latest change. Then, a microtask that will eventually call the real update function is enqueued.

The isScheduled variable acts as a guard to avoid enqueuing multiple redundant microtasks with an empty pendingChanges object.

Conclusion & What's Next

We have just solved the problem of multiple mutations within the same controller execution, so does everything work perfectly now? Not quite... if you think about it for a minute, you might guess our next challenge.

What happens with $scope.person.name = 'Mario'? Until now, we only support changes on top-level properties, but here we are updating a nested property. We will encounter the exact same problem with arrays.

In the next article, we'll dive into how to track, solve, and notify this kind of deep changes.

Thanks for reading! I’m a Frontend Architect passionate about compilers, reactivity, and performance. Let's connect on LinkedIn to stay updated with the next parts of this journey.

From Angular.js to Fine-Grained Reactivity: Part 2 — The JS Proxy Runtime

Carlo Straccialini — Sun, 05 Jul 2026 21:55:01 +0000

In the first article of this series, we saw how a custom build-time compiler can transform a legacy Angular.js template into raw, optimized JavaScript.

To recap, starting from this template:

<!-- simple.html -->
<p>Hello {{ name }}!</p>

Our Go compiler generates the following JavaScript module:

// simple.js
export function template() {
    const p_0 = document.createElement("p");
    const text_1 = document.createTextNode("");
    p_0.append(text_1);

    return {
        mount(container) {
            container.append(p_0);
        },
        update(change) {
            if ("name" in change) {
                text_1.data = "Hello " + change.name + "!";
            }
        }
    }
}

This is incredibly clean. By running template(), we get an object with mount and update methods.

Using mount is fully intuitive: we pass a reference to a DOM element, and it injects our empty paragraph (p_0) into it:

import { template } from './simple.js';

const { mount, update } = template();
const container = document.getElementById('view-container');

mount(container); 
// The DOM now contains: <p></p> (waiting for data)

However, the paragraph remains empty until we call update with a change object like this:

let changes = {
    name: "Mario",
};

update(changes);
// The DOM surgically updates to: <p>Hello Mario!</p>

But who is responsible for tracking changes in our application state, building this changes object, and calling update?

The answer lies in marrying the legacy Angular.js $scope with the modern JavaScript Proxy API.

The Legacy State Pattern

In a traditional Angular.js application, developers mutate the state directly inside a controller by assigning properties to the $scope object:

// simple-controller.js
export function SimpleController($scope) {
    $scope.name = "Mario";
}

To bridge the gap between this legacy controller and our new build-time template, we need a way to automatically capture the assignment $scope.name = "Mario" and translate it into a structured update:

let changes = {
    name: "Mario"
};

Instead of running a heavy runtime digest cycle to dirty-check the entire scope, we can intercept these mutations at the exact moment they happen. This is where Proxies shine.

How the JavaScript Proxy API Saves the Day

The Proxy object allows us to wrap a target object and intercept fundamental operations, such as property lookups, assignments, and function invocations.

By wrapping our $scope in a Proxy before passing it to the controller, we can execute custom code whenever a property is set.

Let's look at how we can implement a basic set trap:

import { SimpleController } from './simple-controller.js';

// Define a handler with a "set" trap
const handler = {
    set(target, prop, value) {
        console.log(`Property "${prop}" changed to: ${value}`);

        // Actually set the value on the target object
        target[prop] = value;

        // The set trap must return true in strict mode
        return true; 
    }
};

// Wrap an empty object with our Proxy handler
const $scope = new Proxy({}, handler);

// Run the legacy controller with our reactive scope
SimpleController($scope); 
// Console logs: Property "name" changed to: Mario

Every time the controller executes $scope.name = "Mario", our Proxy intercepts the assignment. We now have a lightweight, non-invasive mechanism to capture state mutations in real time.

Putting It All Together: The Runtime Connection

Now we can connect our Proxy-based $scope directly to the update method generated by our compiler.

Here is the complete runtime implementation:

import { SimpleController } from './simple-controller.js';
import { template } from './simple.js';

// 1. Initialize the compiled template and mount it
const { mount, update } = template();
const container = document.getElementById('view-container');
mount(container);

// 2. Create the reactive $scope using a Proxy
const $scope = new Proxy({}, {
    set(target, prop, value) {
        // Intercept mutation, build the change object, and trigger the DOM update
        update({ [prop]: value });

        // Propagate the change to the underlying object using Reflect
        return Reflect.set(target, prop, value);
    }
});

// 3. Execute the controller to trigger the initial render
SimpleController($scope);

The result:

The controller runs and executes $scope.name = "Mario".
The Proxy intercepts the write and immediately triggers update({ name: "Mario" }).
The compiled update function surgically targets the TextNode and updates the text to "Hello Mario!".
Zero dirty-checking, zero Virtual DOM, zero external dependencies.

What’s Next?

While this reactive loop is extremely elegant, real-world enterprise applications are rarely this simple.

What happens when a controller updates multiple properties in a row? In our current basic implementation, changing three properties sequentially would trigger three immediate, synchronous DOM repaints. To prevent layout thrashing, we need to implement a batching mechanism to queue updates and flush them once per frame.

Furthermore, how do we handle nested objects, arrays, and dependency tracking (Signals)?

In the next part of this series, we will explore how we scaled this runtime architecture to handle production-grade state management. Stay tuned!

Thanks for reading! I’m a Frontend Architect passionate about compilers, reactivity, and performance. Let's connect on LinkedIn to stay updated with the next parts of this journey.

From Angular.js to Fine-Grained Reactivity: Compiling Templates at Build-Time

Carlo Straccialini — Thu, 25 Jun 2026 10:12:21 +0000

We are in 2026, but in some corners of the enterprise world, it still feels like 2014. One of those places is the frontend stack of my current company.

Over a decade ago, when we launched as a new digital retail bank in the Italian market, we had to choose our technology foundation. We adopted a third-party product—a widget container—that brought Angular.js along as its primary frontend framework.

Fast forward ten years: hundreds of banking features have been shipped, and our architecture has ballooned into a massive fleet of about 450 Angular.js widgets. Today, our codebase is colossal, making a traditional "rip-and-replace" migration look like an impossible mountain to climb.

Yet, staying still is no longer an option:

The Legacy Trap: Critical external dependencies—including Angular.js itself—are no longer maintained, posing security and compliance risks.
Architecture Friction: Integrating modern architectural patterns or modern design systems is extremely hard without adopting fragile workarounds (like heavy Web Component wrappers).
The Talent Crunch: Hiring junior or mid-level developers has become an uphill battle. No one wants to build a career on a tech stack from 2012; the market speaks React, Vue, and modern Angular.

Our Path

During the pandemic, our internal team took the first big step toward freedom: we completely ripped out the legacy third-party widget container and replaced it with a custom, in-house solution. With that constraint gone, the Angular.js lock-in was officially broken.

We faced two clear paths for the migration:

The Traditional Route: Pick a modern framework, hire a massive IT consulting company, and spend millions of euros over a risky, 2-year rewrite—only to potentially find ourselves in the exact same legacy trap a decade from now.
The Engineer's Route: Develop a custom solution internally, just as we successfully did for our widget container.

Driven by engineering pragmatism, we chose the second path. Inspired by the build-time philosophy of Svelte and the fine-grained reactivity of Solid.js, we decided to build a custom compiler. Our goal? Transform legacy Angular.js HTML templates into highly optimized, modern JS modules based on fine-grained reactivity—without changing a single line of our existing template or controller files.

The Core Concepts

To understand how we achieved this, let's look at how Angular.js works under the hood.

<!-- Template -->
<p>Hello {{ name }}!</p>

// Controller
function SimpleController($scope) {
    $scope.name = "Mario";
}

At runtime, the framework parses the template, reads the $scope object, and replaces the dynamic variables to output vanilla HTML:

<p>Hello Mario!</p>

This mechanism is driven by the Angular.js Digest Cycle. During this cycle, the framework evaluates all dynamic expressions (interpolations between {{ and }}) and recomputes their values to check for changes.

Doing this at scale is an incredibly expensive operation. Because the browser doesn't natively know which specific part of the DOM needs an update, a single property change on a $scope can trigger a dirty-checking loop across the entire view.

Shifting to Build-Time: What Can We Do?

Our golden constraint was strict: do not touch the template or controller source code. Starting from the exact same template:

<!-- Template -->
<p>Hello {{ name }}!</p>

We built a custom template compiler (written in Go) that processes this HTML at build-time and outputs highly efficient, raw JavaScript:

// Compiled JavaScript Output
function template() {
    const p_0 = document.createElement("p");
    const text_1 = document.createTextNode("");
    p_0.append(text_1);

    return {
        mount(container) {
            container.append(p_0);
        },
        update(change) {
            if ("name" in change) {
                text_1.data = "Hello " + change.name + "!";
            }
        }
    }
}

This compiled function returns an object with two lifecycle methods:

mount: Used by our lightweight runtime to inject the element into the DOM container.
update: The real heart of our framework. When a property changes, this function targets and mutates one specific TextNode in the DOM, surgically updating the UI.

The browser no longer needs to scan the entire page. Instead, the runtime immediately knows that when name changes, this exact update function must be invoked.

But how does the runtime intercept these changes without a digest cycle? This is where the modern JavaScript Proxy API comes into play—and that is exactly what we will explore in the next part of this series.

Thanks for reading! I’m a Frontend Architect passionate about compilers, reactivity, and performance. Let's connect on LinkedIn to stay updated with the next parts of this journey.