Carlo Straccialini

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

Carlo Straccialini — Tue, 30 Jun 2026 00:00:00 GMT

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.

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

Carlo Straccialini — Sun, 05 Jul 2026 00:00:00 GMT

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: Part 3 — How to Optimize the Render Phase

Carlo Straccialini — Wed, 29 Jul 2026 00:00:00 GMT

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 sameupdatefunction causes a redraw of the browser window so the user can finally see "Mario 24" (assuming the result ofcomputeAge()` 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.