There are various techniques available that enable the browser to retain a single page even when the application requires server communication.
Document hashes HTML authors can leverage element IDs to show or hide different sections of the HTML document. Then, using CSS, authors can use the :target pseudo-class selector to only show the section of the page which the browser navigated to.
JavaScript frameworks Web browser JavaScript frameworks and libraries, such as
Angular,
Ember.js,
ExtJS,
Knockout.js,
Meteor.js,
React,
Vue.js, and
Svelte have adopted SPA principles. Aside from ExtJS, all of these are free. •
AngularJS is a discontinued fully client-side framework. AngularJS's templating is based on bidirectional
UI data binding. Data-binding is an automatic way of updating the view whenever the model changes, as well as updating the model whenever the view changes. The HTML template is compiled in the browser. The compilation step creates pure HTML, which the browser re-renders into the live view. The step is repeated for subsequent page views. In traditional server-side HTML programming, concepts such as controller and model interact within a server process to produce new HTML views. In the AngularJS framework, the controller and model states are maintained within the client browser. Therefore, new pages are capable of being generated without any interaction with a server. •
Angular 2+ is a SPA Framework developed by Google after AngularJS. There is a strong community of developers using this framework. The framework is updated twice every year. New features and fixes are frequently added in this framework. •
Ember.js is a client-side JavaScript web application framework based on the
model–view–controller (MVC) software architectural pattern. It allows developers to create scalable single-page applications by incorporating common idioms and best practices into a framework that provides a rich object model, declarative two-way data binding, computed properties, automatically updating templates powered by Handlebars.js, and a router for managing application state. •
ExtJS is also a client side framework that allows creating MVC applications. It has its own event system, window and layout management, state management (stores) and various UI components (grids, dialog windows, form elements etc.). It has its own class system with either dynamic or static loader. The application built with ExtJS can either exist on its own (with state in the browser) or with the server (e.g. with
REST API that is used to fill its internal stores). ExtJS has only built in capabilities to use localStorage so larger applications need a server to store state. •
Knockout.js is a client side framework which uses templates based on the
Model-View-ViewModel pattern. •
Meteor.js is a full-stack (client-server) JavaScript framework designed exclusively for SPAs. It features simpler data binding than Angular, Ember or ReactJS, and uses the
Distributed Data Protocol and a
publish–subscribe pattern to automatically propagate data changes to clients in real-time without requiring the developer to write any synchronization code. Full stack reactivity ensures that all layers, from the database to the templates, update themselves automatically when necessary. Ecosystem packages such as
Server Side Rendering address the problem of search engine optimization. •
React is a
JavaScript library for building
user interfaces. It is maintained by
Facebook,
Instagram and a community of individual developers and corporations. React uses a syntax extension for JavaScript, named
JSX, which is a mix of JS and HTML (a subset of HTML). Several companies use React with
Redux (JavaScript library) which adds state management capabilities, which (with several other libraries) lets developers create complex applications. •
Vue.js is a JavaScript framework for building user interfaces. Vue developers also provide Pinia for state management. •
Svelte is a framework for building user interfaces that compiles Svelte code to JavaScript DOM (Document Object Model) manipulations, avoiding the need to bundle a framework to the client, and allowing for simpler application development syntax.
Capabilities and trade-offs in modern frameworks JavaScript-based web application frameworks, such as React and Vue, provide extensive capabilities but come with associated trade-offs. These frameworks often extend or enhance features available through native web technologies, such as routing, component-based development, and state management. While native web standards, including Web Components, modern JavaScript APIs like Fetch and ES Modules, and browser capabilities like Shadow DOM, have advanced significantly, frameworks remain widely used for their ability to enhance developer productivity, offer structured patterns for large-scale applications, simplify handling edge cases, and provide tools for performance optimization. Frameworks can introduce abstraction layers that may contribute to performance overhead, larger bundle sizes, and increased complexity. Modern frameworks, such as React 18 and Vue 3, address these challenges with features like concurrent rendering, tree-shaking, and selective hydration. While these advancements improve rendering efficiency and resource management, their benefits depend on the specific application and implementation context. Lightweight frameworks, such as Svelte and Preact, take different architectural approaches, with Svelte eliminating the virtual DOM entirely in favor of compiling components to efficient JavaScript code, and Preact offering a minimal, compatible alternative to React. Framework choice depends on an application’s requirements, including the team’s expertise, performance goals, and development priorities. These solutions emphasize
progressive enhancement,
server-side rendering, and optimizing performance. Astro renders static HTML by default while hydrating only interactive parts. Fresh focuses on server-side rendering with zero runtime overhead. Enhance.dev prioritizes progressive enhancement patterns using Web Components. While these tools reduce reliance on client-side JavaScript by shifting logic to build-time or server-side execution, they still use JavaScript where necessary for interactivity. This approach makes them particularly suitable for performance-critical and content-focused applications.
Browser plugins Although this method is outdated, asynchronous calls to the server may also be achieved using browser plug-in technologies such as
Silverlight,
Flash, or
Java applets.
Data transport (XML, JSON and Ajax) Requests to the server typically result in either raw data (e.g.,
XML or
JSON), or new
HTML being returned. In the case where HTML is returned by the server, JavaScript on the client updates a partial area of the DOM (
Document Object Model). When raw data is returned, JavaScript on the client translates it into HTML using
XSL or a JSON
template before updating the DOM.
Server architecture Thin server architecture A SPA moves logic from the server to the client, with the role of the web server evolving into a pure data API or web service. This architectural shift has, in some circles, been coined "Thin Server Architecture" to highlight that complexity has been moved from the server to the client, with the argument that this ultimately reduces overall complexity of the system.
Thick stateful server architecture The server keeps the necessary state in memory of the client state of the page. In this way, when any request hits the server (usually user actions), the server sends the appropriate HTML and/or JavaScript with the concrete changes to bring the client to the new desired state (usually adding/deleting/updating a part of the client DOM). At the same time, the state in server is updated. Most of the logic is executed on the server, and HTML is usually also rendered on the server. In some ways, the server simulates a web browser, receiving events and performing delta changes in server state which are automatically propagated to client. This approach needs more server memory and server processing, but the advantage is a simplified development model because a) the application is usually fully coded in the server, and b) data and UI state in the server are shared in the same memory space with no need for custom client/server communication bridges.
Thick stateless server architecture This is a variant of the stateful server approach. The client page sends data representing its current state to the server, usually through Ajax requests. Using this data, the server is able to reconstruct the client state of the part of the page which needs to be modified and can generate the necessary data or code (for instance, as JSON or JavaScript), which is returned to the client to bring it to a new state, usually modifying the page DOM tree according to the client action that motivated the request. This approach requires that more data be sent to the server and may require more computational resources per request to partially or fully reconstruct the client page state in the server. At the same time, this approach is more easily scalable because there is no per-client page data kept in the server and, therefore, Ajax requests can be dispatched to different server nodes with no need for session data sharing or server affinity. ==Running locally==