I Ditched React and Built a Zero-Allocation Vanilla JS App. Here is What I Learned.

Halil Acar — Thu, 02 Jul 2026 13:47:41 +0000

As a DevOps engineer and a competitive powerlifter, I rely heavily on math during my training sessions. Recently, I got frustrated with the state of modern fitness web apps. They often ship megabytes of JavaScript, rely on heavy frameworks, and suffer from layout thrashing just to calculate simple barbell math.

I decided to build my own platform, PeakLoads.com, from scratch. The goal was simple: 100% Vanilla JS, zero dependencies, and a strict "Zero-Allocation" architecture to completely eliminate Garbage Collection (GC) pauses on the main thread.

Here are the core architectural decisions and micro-optimizations that allowed me to achieve sub-millisecond render times.

1. The Hidden Cost of dataset (DOMStringMap)

Modern tutorials tell you to use element.dataset.value to read data-* attributes. However, accessing the dataset property dynamically creates or utilizes a DOMStringMap proxy object behind the scenes. In a hot loop, this causes massive memory allocation overhead.

The Fix: Always use the native C++ boundary API getAttribute().

// Bad: Allocates memory for DOMStringMap proxy
const value = el.dataset.i18n;

// Good: Zero-allocation, direct string access
const value = el.getAttribute('data-i18n');

2. Eliminating Temporary Arrays in Hot Paths

Functional programming methods like .map(), .filter(), and .reduce() are clean, but they create intermediate arrays that the V8 Garbage Collector eventually has to clean up. When generating dynamic tables (like a 1RM percentage chart), this creates unnecessary memory pressure.

The Fix: Pre-allocate arrays and use primitive index-based for loops.

// Bad: Dynamic resizing and iterator overhead
const result = [];
data.forEach(item => result.push(item * 2));

// Good: Pre-allocated memory and primitive loop
const expectedLength = data.length;
const result = new Array(expectedLength);
for (let i = 0; i < expectedLength; i++) {
    result[i] = data[i] * 2;
}

3. Zero-Allocation O(1) Dictionary Lookups

When building a complex matrix (like an RPE to 1RM translation table), developers usually combine strings to create dictionary keys. String concatenation (reps + '_' + rpe) allocates new memory for every single lookup.

The Fix: Derive zero-allocation integer keys using deterministic mathematical formulas. The V8 engine resolves integer hashes exponentially faster than string keys.

// Bad: String concatenation allocates memory
const key = reps.toString() + '_' + rpe.toString();
const percentage = matrix[key];

// Good: Deterministic integer math
const key = (reps * 100) + (rpe * 10);
const percentage = matrix[key];

4. Write-Through Cache for Synchronous Disk I/O

Synchronous operations like localStorage.setItem are thread-blocking. If you tie your state-saving logic to global input or change event listeners, the browser performs redundant disk writes for the exact same state strings, heavily degrading the Interaction to Next Paint (INP) metric.

The Fix: Implement a primitive Write-Through Cache mechanism using strict equality checks to intercept redundant writes before they hit the disk.

const SafeStorage = {
    _lastWritten: {},

    setItem(key, value) {
        // Intercept redundant disk I/O instantly
        if (this._lastWritten[key] === value) return;

        this._lastWritten[key] = value;
        localStorage.setItem(key, value);
    }
};

The Result

By adhering to these rules, PeakLoads handles complex asymptotic decay algorithms, UI state hydration, and DOM mutations in under 0.20ms per execution tick. No virtual DOM diffing, no framework overhead, just hardware-accelerated execution.

Sometimes, stepping away from the modern toolchain and writing mechanical, memory-conscious JavaScript is the best optimization you can make.

If you want to see the performance in action, you can test the calculators at peakloads.com.