What is the fundamental difference between client-side and server-side routing?
You know server routing fetches HTML pages, while client routing runs in the browser.
Server routes return full documents and reload; client routes swap JS views and use the History API without server requests.
What's really being asked
This question checks whether you understand the architectural boundary between the server and the browser in modern web applications. Interviewers want to see that you recognize the web began as static documents delivered by servers, and that client-side frameworks shifted much of that responsibility into the browser. It is not enough to name the technologies; you must explain who owns the navigation lifecycle and the document.
The full answer
A strong response hits four things in order. First, it defines server-side routing as a model where every URL change sends an HTTP request to the server, which responds with a complete new HTML document and triggers a full page reload. Second, it defines client-side routing as a model where the browser intercepts navigation, dynamically swaps rendered components using JavaScript, and updates the visible URL via the History API without requesting a new document from the server. Third, it notes that frameworks provide opinions and structure for this behavior, bringing predictability and maintainability to an otherwise complex client-driven architecture. Fourth, it mentions the trade-offs, such as the need for a server fallback to handle initial page loads or deep links correctly.
The mistakes people make
Red flags include describing the difference as only speed or claiming that client-side routing eliminates the server entirely. Another weak pattern is saying that React Router changes the URL in the address bar but failing to explain that the browser does not fetch a new HTML document. Some candidates also confuse routing with rendering and talk about virtual DOM diffing instead of navigation ownership.
What usually comes next
An interviewer might ask how to handle deep linking or direct URL access in a client-side routed application, which requires server configuration to serve the same bootstrap HTML for all routes. They may also ask about the History API and how pushState or replaceState enable URL changes without reloads. Another common follow-up is the impact on accessibility and how to announce route changes to screen readers.
A concrete example
Imagine a user clicking a navigation link in a React application. With client-side routing, React Router prevents the default browser request, renders the new component tree, and calls history.pushState to update the URL to slash products. The server is never contacted for a document; only subsequent API calls for data might hit the network. In a server-side routing model, that same click would request slash products from the server, which would return a wholly new HTML page and the browser would tear down and rebuild the entire document context.
Interview question
When a user clicks an internal link, what fundamentally distinguishes client-side routing from server-side routing?
- a.Client-side routing intercepts navigation, swaps views with JavaScript, and updates the URL without fetching a new HTML document from the server.Correct
- b.Client-side routing is primarily a performance technique that preloads pages to make navigation faster than server-side routing.
- c.Client-side routing eliminates the server entirely so the browser can generate all content without any network requests.
- d.Client-side routing uses the virtual DOM to diff updates, whereas server-side routing rebuilds the entire document tree on every navigation.
Why? this is the answer
The correct answer captures the core architectural difference: the browser owns navigation by intercepting clicks and updating views via JavaScript without requesting a new HTML document. The virtual DOM distractor is tempting but wrong because it confuses routing with rendering, when the real distinction is who controls the document lifecycle.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles