Single Page Application

Traditional web pages request a new HTML page from the server and reload the entire page every time a link is clicked. When a user switches tabs on a dashboard, selects an item from a list, or adjusts a filter, the screen flickers and is redrawn from scratch. Music that was playing stops, a form being filled in resets, and the scroll position returns to the top. From the user's perspective, a simple action incurs disproportionate waiting. From the developer's perspective, the server must repeatedly render the same layout and navigation on every request. The more the web must handle complex interaction beyond simple document viewing, the more the round-trip-to-server structure becomes a bottleneck for both user experience and development efficiency.

In the early web, having the server assemble and send complete HTML was the natural approach, since there were few pages and interactions were simple. The arrival of services like Gmail and Google Maps in the 2000s changed that. Fetching the entire page each time an email was opened was an obvious waste, and a scroll on a map that triggered a full refresh made it unusable. As AJAX became ubiquitous, it became possible to asynchronously fetch only partial data without reloading the entire page. On top of that technical foundation, the idea of 'loading just one page from the start and handling everything else with JavaScript' took hold. As browser JavaScript engines improved in speed and frontend frameworks provided systematic support for routing and state management, SPAs became the standard architecture for complex web applications.

In an SPA, when a user first enters a URL, the server sends an almost empty HTML file and a JavaScript bundle. This HTML contains no content -- only an empty container like <div id="root"></div>. The screen is only rendered once the browser downloads and executes the JS bundle. Afterward, when the user navigates to another page, the browser does not request new HTML from the server. JavaScript detects the URL change, finds the component corresponding to that path, and directly updates the DOM. This is client-side routing. When data for display is needed, the API server is asked for JSON, and only the relevant parts of the screen are redrawn with the received data. In this architecture, the server focuses on its role as an API for data exchange, and all screen rendering and user interaction is handled entirely within the browser. Page transitions are fast and application state is preserved, but until the initial JS bundle is received and executed, the user sees a blank screen.

SPA and SSR are both ways to build web applications, but the key difference is where the HTML is produced. An SPA generates the screen with JavaScript in the browser; SSR sends completed HTML from the server. The consequences of this difference are clear. An SPA may have slower initial load times but offers fast subsequent navigation and easy state preservation. SSR shows the first screen quickly and allows search engines to read the content, but the server must regenerate HTML every time the user navigates. Rather than asking 'which is better?', the right question is 'how do users use this app?'. For a service where complex interaction after login is the primary use, SPA is natural. For content-centric sites that need to be indexed by search engines, SSR is preferable. In practice, hybrid approaches combining both are also common.

SPAs are the best fit for services like admin tools, dashboards, and collaboration apps used after login, where user interaction is frequent and state persistence is important. For these services, search engine exposure is not a major concern, and response speed after loading is what determines the user experience. In production, JavaScript bundle size is a critical concern. More features mean a larger bundle and slower initial load times. Code splitting -- loading only the code needed for the current screen -- is essential. For landing pages and public content that require SEO, SPA alone may be insufficient. If search bots cannot execute JavaScript, only a blank page will be indexed. There is no requirement to build every page of an application as an SPA. A common approach in practice is to render public pages on the server and build only post-login pages as an SPA.