{"id":9970,"date":"2026-06-04T11:13:18","date_gmt":"2026-06-04T16:13:18","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=9970"},"modified":"2026-06-04T11:13:48","modified_gmt":"2026-06-04T16:13:48","slug":"navigation-api-baseline","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/navigation-api-baseline\/","title":{"rendered":"Navigation API Baseline"},"content":{"rendered":"\n

If you’ve ever built your own client-side navigation that properly respects updating URLs, you’ve probably used history.pushState()<\/code> a bunch, and it’s a bunch of work getting it robust and right. I think Jay Rungta does a good job of showcasing the newly-baseline Navigation API<\/a> and why it’s better.<\/p>\n\n\n\n

Sorry for the huge blockquote, but it’s worth it:<\/p>\n\n\n\n

\n

Building a router with the History API felt like assembling a puzzle, since you had to:<\/p>\n\n\n\n

    \n
  1. Listen for clicks on <a><\/code> tags globally.<\/li>\n\n\n\n
  2. Call preventDefault()<\/code> on them.<\/li>\n\n\n\n
  3. Manually call history.pushState()<\/code>.<\/li>\n\n\n\n
  4. Manually update your DOM.<\/li>\n\n\n\n
  5. Separately<\/em> listen for the popstate<\/code> event to handle the back\/forward buttons.<\/li>\n<\/ol>\n\n\n\n

    If you forgot to handle one edge case, users might accidentally end up at the wrong view, highlighting its fragility.<\/p>\n\n\n\n

    The Navigation API radically simplifies this. It gives you a single, centralized NavigateEvent<\/a> for every navigation\u2014whether it’s a user clicking a link, submitting a form, hitting the back button, or your code calling navigation.navigate()<\/code>.<\/p>\n\n\n\n

    The event.intercept()<\/code> function does a lot of the heavy lifting for you:<\/p>\n\n\n\n