Why the live examples use memory routers
Browsers only let a page pushState URLs on its own origin. A frame built from a string has no real origin, so the call throws a SecurityError. In your own app, served from http://localhost:5173, it works.
Client-side routing lets a single-page app change the URL and the screen without asking the server for a new HTML page, using the browser's History API; the URL becomes part of your app's state, so pages can be bookmarked, shared and reloaded.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Add a replace(path) method to the tiny router and use it for a "Go to login" button so that Back doesn't return to the page you replaced.
In the filters example, add a sort param with two buttons ("Name" and "Size") and sort the list from the URL.
Write the nginx and Vercel rules you would add to deploy an SPA whose routes include /dashboard/settings.
Explain it without notes
What is the difference between a multi-page app and a single-page app, from the user's and the browser's point of view?
Explain how pushState, replaceState and popstate work together in client-side routing.
Why do SPAs need a server fallback, and why does the bug usually appear only after deploying?
What does "URLs are state" mean, and how do you decide what goes in the URL?
Preview
Console
Nothing logged yet.Expected console output
my address: about:srcdoc
pushState failed: SecurityError