Advanced level · Module 3: Application Architecture without a Framework · Lesson 4 of 4
Client-Side Routing and Choosing a Framework
Navigate between screens without full page reloads using the History API, and decide when a framework is worth adopting.
In this lesson you will
- Implement client-side routing with the History API
- Evaluate when to use a front-end framework
Key concepts
History APIpopstateroute tableframework trade-offs
The lesson
A single-page application changes screens without reloading. history.pushState updates the URL; listening for popstate handles the back button; a route table maps paths such as /visits/42 to view functions.
Links must still work: intercept clicks on internal links, push the new URL and render the matching view. The server must return the app for every route so that refreshing a deep link works.
Frameworks such as React, Vue and Svelte package these patterns — components, state, routing — with large ecosystems. Adopt one when an app's size or team benefits from conventions; for small, offline-first tools on modest phones, plain JavaScript is often lighter and faster.
Step by step
- Create a route table for three screens.
- Intercept internal link clicks and use pushState.
- Handle the back button with popstate.
- Write a short comparison of your router with a framework's.
Practice activity
Add routing to the visit tracker so that each screen has its own URL and the back button works.
Expected result: Every screen has a URL, deep links work after refresh on the dev server and the back button returns to the previous screen.
Check your understanding
-
Which method changes the URL without reloading?
Show answer
history.pushState.
-
Which event fires when the user presses the back button?
Show answer
popstate.
Taught live by an instructor — online or in person. Free course lessons are for self-study and do not lead to a certificate — see registration options.