The Secret Life of JavaScript: The Proxy

Defeating the Dinosaur with Service Workers

#JavaScript #WebPerformance #Frontend #ServiceWorkers

Margaret is a senior software engineer. Timothy is her junior colleague. They work in a grand Victorian library in London — the kind of place where code quality is the unspoken objective, and craftsmanship is the only thing that matters.

Episode 27

The Dinosaur

Timothy stared at his monitor, his shoulders slumped in defeat. On his screen was the dreaded, pixelated Chrome dinosaur standing over a bleak, offline desert.

"The dashboard is perfectly optimized," Timothy sighed, leaning back as Margaret approached with her dark roast coffee. "We moved all the heavy data parsing to a Web Worker. The Main Thread is pristine. The animations are a flawless sixty frames per second. But none of that matters because the client's CEO took his laptop on a subway, lost Wi-Fi for two minutes, and the entire application just vanished."

Margaret looked at the dinosaur and took a sip of her coffee.

"You built a world-class restaurant with a lightning-fast kitchen," Margaret said. "But the moment the delivery trucks hit traffic, you kicked all your customers out into the street. You need someone managing the front door."

The Maître D'

"Last week, we hired a sous-chef," Margaret explained, uncapping a dry-erase marker. "We used a Web Worker to spin up a parallel thread strictly for heavy CPU computation. Today, we are going to hire a maître d' to handle network interception. We are going to use its sibling: the Service Worker."

She drew a diagram showing the browser, the network, and a distinct layer sitting right in the middle.

"A Service Worker is a script that runs entirely independently of your webpage," Margaret continued. "It acts as a programmable network proxy, allowing you to intercept network requests, cache assets, and serve responses even when the network is completely unavailable. Once installed, every single network request your application makes within the worker's scope—for images, CSS, API data, or the HTML itself—flows through the Service Worker first. If the internet goes down, the maître d' intercepts the failed request and serves the customer a cached version of the menu from the dining room, completely shielding them from the outage."

The Intercept

Timothy split his code. First, he registered the new worker in his main application file.

// main.js - Hiring the Maître D'
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js')
      .then(reg => console.log('Service Worker registered!', reg.scope))
      .catch(err => console.error('Registration failed:', err));
  });
}

Then, he built the logic for the proxy in a dedicated sw.js file. He set up three critical event listeners: one to cache the core assets, one to clean up old caches, and one to intercept the network traffic.

// sw.js - The Front Door Proxy
const CACHE_NAME = 'dashboard-v1';
const CORE_ASSETS = [
  '/',
  '/index.html',
  '/styles.css',
  '/app.js',
  '/offline-logo.png'
];

// 1. Install Phase: Stock the dining room
// The install event only runs once per version of the Service Worker
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then((cache) => cache.addAll(CORE_ASSETS))
  );
});

// 2. Activate Phase: Clean out old menus (cache busting)
self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(
        keys.filter(key => key !== CACHE_NAME)
            .map(key => caches.delete(key))
      )
    )
  );
});

// 3. The Intercept: Manage the front door
// Cache-First strategy: try cache, then network
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((cachedResponse) => {
        // If we have it, serve it instantly (even if offline)
        if (cachedResponse) {
          return cachedResponse;
        }
        // Otherwise, let the request go out to the network
        return fetch(event.request);
      })
  );
});

Defeating the Desert

"Look at the power of that interception," Margaret said, pointing to the event.respondWith() block. "You have completely hijacked the browser's default network behavior. By checking the cache first and falling back to the network, you just implemented a Cache-First strategy. Other strategies—like Network-First or Stale-While-Revalidate—are entirely possible depending on your app's needs. But here, when the browser asks for index.html, the Service Worker catches the request, realizes it already saved a copy, and returns it immediately."

"This is the foundation of Progressive Web Apps (PWAs)," she added. "Just remember two golden rules: because they are so powerful, browsers mandate that Service Workers only run over secure HTTPS connections. And because of their unique lifecycle, a newly updated worker won't fully take control—meaning it won't intercept top-level navigation requests like loading your page—until all existing tabs of the app are closed, unless you explicitly tell it to skip waiting."

Timothy saved the files and refreshed the dashboard to install the worker. Then, he opened his Chrome DevTools, navigated to the Network tab, and deliberately toggled his connection to "Offline."

He held his breath and clicked the refresh button.

The dinosaur did not appear. Instead, the dashboard loaded instantly. The HTML structure, the CSS grid, and the JavaScript framework all rendered perfectly. The data grid was empty, pending a live connection, but the application itself was alive, responsive, and fully intact.

Timothy had effectively defeated the offline desert. The maître d' had saved the restaurant, and his threading architecture was finally complete.

Aaron Rose is a software engineer and technology writer at tech-reader.blog.

Catch up on the latest explainer videos, podcasts, and industry discussions below.

Search This Blog

Tech-Reader.blog