Frontend Is Edge Computing

A series about the work we've been doing all along — and what changes when we name it correctly.

For twenty years we've treated the browser as a thin presentation layer — a rendering target for data produced somewhere else. That framing made sense when web pages were documents. It stopped making sense the moment we started shipping applications that orchestrate thousands of API calls, persist gigabytes of client state, coordinate across tabs and devices, and expect to keep running when the network drops.

The browser isn't a client anymore. It's the edge of your distributed system. It's the node closest to the user, running on hardware you don't own, over a network you don't control, inside a resource sandbox you can't expand. Everything we know about distributed systems — backpressure, circuit breakers, deduplication, caching tiers, graceful degradation, observability — applies there. What doesn't apply, increasingly, is the mental model most of us were trained on: "the frontend just renders."

This series is my attempt to redraw the map. Each post takes one assumption that backend and platform engineers carry into frontend work and replaces it with the mental model the browser actually demands.

The Series

  1. Frontend Is Edge Computing — The thesis. Why the browser deserves to be treated as a first-class compute node in your architecture, and what changes when you do.
  2. The Single-Threaded Covenant (coming soon) — Why the browser runs on one thread, why that's not a bug, and what it means for everything you build.
  3. The Engines That Run Your Code (coming soon) — JIT compilers, hidden classes, and why the same code behaves differently depending on which browser your user prefers.
  4. When Server Patterns Break at the Edge (coming soon) — Singletons, DI containers, repositories, observers. The design patterns you've trusted for a decade, and why half of them will leak memory the moment you port them.
  5. The True Cost of the DOM (coming soon) — Why painting HTML is your most expensive operation, what layout thrashing really is, and how to live inside a 16ms budget.
  6. Web Workers and the Limits of Parallelism (coming soon) — The only real escape hatch for CPU-bound work at the edge — and the message-passing costs that make it interesting.
  7. Memory in a Shared Sandbox (coming soon) — Why every byte counts, how leaks happen silently, and the structures that let the garbage collector help you.
  8. Architecting for the Edge (coming soon) — Circuit breakers, request deduplication, optimistic updates, state tiers, progressive enhancement. The pattern language of browser-native distributed systems.

Who I Am

I build platforms that other engineering teams depend on — and I've been doing it at the scale of a major cloud provider for seven years.

I was the sole architect behind a browser-based global inventory console that orchestrates roughly a thousand concurrent API calls across thirty-plus regions to deliver a unified view of a customer's worldwide infrastructure in under five seconds — with zero backend infrastructure cost. When no global API exists, you build one at the edge. That product serves over a million customers per month, and I've owned it end-to-end for five years: architecture, implementation, operations, and on-call.

Alongside that, I own the primary console for one of the industry's most foundational networking products — the management interface for virtual networks, subnets, routing, gateways, and security policy — which functions as both a product used by millions of customers and a platform that other engineering teams build their own consoles on top of.

My technical depth spans frontend architecture (React, TypeScript, microfrontends), distributed systems design, client-side API orchestration, performance engineering (IndexedDB, caching, adaptive throttling, progressive rendering), and cloud infrastructure. I've shipped across the stack — React Native mobile, serverless backends, and the browser-edge orchestration systems this series is about.

What sets me apart isn't that I build features. It's that I design the technical platforms and systems that let other engineering teams ship faster. I've spent my career in high-autonomy, high-ownership environments — architecting, implementing, operating, and being on-call for the systems I build.

Core stack: TypeScript, React, Node.js, cloud infrastructure (compute, networking, serverless, queues, object storage, observability, client-side storage), microfrontend architecture, CI/CD, infrastructure-as-code.

Start here: Frontend Is Edge Computing →