The City Planner's Ghost Train: On the Paradox of Pre-Emptive Optimization

I live near an old railway bridge that crosses a river on the edge of town. It’s a beautiful, rusting iron lattice, but it’s been decades since any train used it. It was built in anticipation of an industrial boom that never arrived. Every day, people walk their dogs beneath it, and I can’t help but think about the web we build. Specifically, I think about the grand infrastructure we erect in the name of speed—the complex service worker architectures, the sprawling webpack configurations, the intricate caching layers—for projects that, like the towns around my bridge, may never see the traffic to justify them.

In urban planning, this is sometimes called a ‘ghost train’ or a ‘white elephant’: an expensive, fixed-capacity solution built for a predicted future demand that fails to materialize. The cost isn’t just in the steel and concrete; it’s in the perpetual maintenance, the visual blight, and the opportunity cost of what simpler, more adaptable infrastructure could have been built instead. On the web, our version of this is the pre-emptive, over-engineered performance optimization. We build the bridge for ten thousand daily trains before we’ve laid the first track to a single station.

The Weight of an Empty Viaduct

The parallel is most painful in the JavaScript we ship. We reach for the most sophisticated state management library, the heaviest framework with the most granular hydration, because it promises to scale. Yet, the initial payload—the empty viaduct—is a permanent tax on every single user, from the first to the hypothetical ten-thousandth. We’ve prioritized the fantasy of future efficiency over the tangible reality of present latency. The city planner in us is seduced by the blueprint of a metropolis, forgetting that people need to cross the stream today, and a simple, sturdy footbridge would do.

This isn’t an argument against planning. It’s an argument for a different kind of craft, one borrowed from tactical urbanism. This approach starts with a ‘pop-up’—a minimal, functional solution. A single, well-optimized route. A handful of critical static pages. It observes real usage patterns. Where do the natural paths form? Which assets are truly, repeatedly needed? Only then, and only where congestion actually appears, do you pave the path. You pour the concrete where the dirt is already worn.

Applied to front-end craft, this means our default posture should be lean delivery. It means measuring real Core Web Vitals on real traffic before we decide to architect a solution for their hypothetical degradation. It means that a ‘Cache-Control’ header is often a more responsive piece of infrastructure than a full-blown CDN edge-function rewrite. The most stable layout is often the one that didn’t wait for three npm packages to paint. Sometimes, the optimal performance strategy is to build less—to defer the grand bridge until you can hear the whistle of the approaching train.

My rusting bridge is now a historical monument, a lesson in cast iron and ambition. Our web projects shouldn’t be. By borrowing the city planner’s hindsight, we can learn to build for the traffic we have, with the materials at hand, and leave space for the graceful, necessary expansion that only proven demand can justify. The quiet, swift experience of the present user will always be more valuable than the ghost of a fast future.

Notes & further reading

A few pages I came back to while writing this: