Frontend Routing Is Just a Mapping Table and a DOM Swap
Modern routers hide the machinery behind configuration DSLs, but every SPA navigation still boils down to a lookup table and a DOM swap. Understanding the raw `hashchange` mechanism makes debugging routing bugs, choosing between hash and history mode, and reasoning about SSR versus client-side rendering straightforward instead of magical.
A hand-written HashRouter in vanilla JavaScript strips frontend routing down to its core: a path-to-callback mapping table and a `hashchange` event listener. The `#` in a URL was originally designed for in-page anchors, so browsers never send a request when it changes. Frontend frameworks exploit this to intercept navigation and replace only the relevant DOM fragment, eliminating the white flash of a full page load. The implementation exposes a classic JavaScript pitfall where event handlers rebind `this` to `window`, breaking access to the route table unless explicitly bound with `bind`, `call`, or an arrow function. Hash routing's limitations — ugly URLs, poor SEO, anchor conflicts, and server invisibility — are what later pushed the ecosystem toward the History API, but the underlying mental model stays the same.
The article's framing — that modern routers are just prettier wrappers around a mapping table and an event — is a useful corrective to framework mystique, though it understates how much complexity nested routes, lazy loading, and guards add in practice.
Treating the `this` binding pitfall as a routing-specific lesson is smart pedagogy; it anchors a dry language mechanic to a concrete, breakable demo that every frontend developer will encounter.
The open question about coexisting anchor links and hash routes hints at a real-world tension the article doesn't resolve: once you hijack the hash for routing, you lose native in-page scrolling unless you build a custom scroll manager on top.