DEV Community: Carlo Straccialini

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.