An SPA loads once. After that, nothing pulls a fresh page from the server no matter how much you click around. That's the whole trick. Gmail works this way. So does Google Maps. The URL might change, the content on screen definitely changes, but the browser isn't going back to the server for a new HTML document the way it would on a normal site. Everything happens in JavaScript, in the browser, after that first load.
Picking the wrong framework for this doesn't show up on day one. It shows up eight months later, when the state has tangled into a mess and nobody can explain why one click re-renders half the page.
React is still the default. Meta built it, keeps maintaining it, and the ecosystem is deep enough that most problems already have a published library. Angular plays a different game. Google shipped it as a complete framework with TypeScript baked in, routing and data binding included, so you're not stitching together five separate packages just to get something working. Vue lands in between the two. Lighter than Angular, less opinionated than React about how you're supposed to manage state, which is exactly why smaller teams tend to reach for it first.
Svelte skips the pattern altogether. It doesn't ship a virtual DOM to the browser at all. It compiles components down to plain JavaScript at build time, and that's a big part of why Svelte apps usually end up with smaller bundles than the same thing built in React.
This blog covers what's actually available for building single page applications right now, where React, Angular, and Vue genuinely diverge, and where Svelte and the rest of the field fit in.
Single Page Application: An Overview
A single page application, or SPA, loads one HTML page and never leaves it. Everything after that first load happens through JavaScript rewriting parts of the page. No new document ever comes from the server. This is the foundation every single page application framework is built to manage.
Twitter's feed is a clean example. Scroll and new tweets load into the same page shell. Nothing reloads, nothing flashes white, and the header stays put the entire time. That single behavior, updating content without a full page reload, is the entire foundation that single page application development is built on. Every framework covered in this guide exists to manage that behavior at scale, once a page has more moving parts than a feed.
What is Single Page Application Architecture?
SPA architecture means the page doesn't go back to the server for a new document every time you click something. It rewrites the DOM in place instead. A multi-page site fetches a fresh page on every navigation, and even a fast fetch shows up as a flicker or a half-second stall. On a checkout flow, that stall is where people abandon carts. This makes SPAs particularly useful for interactive digital products where smooth navigation and responsive interfaces are important to software product development.
That's the actual case for SPAs in digital commerce: fewer places for someone to lose momentum mid-purchase.
What Technologies Are Used in Single Page Applications?
An SPA still talks to a server. It just doesn't reload the page to do it. Here's what the actual single page application technologies behind that are.
1. Client-side routing
The address bar changes without a request going out, and that's the History API doing its job. pushState updates the URL. popState catches it when someone hits back or forward, so the app can swap the view to match. Before this existed, developers faked routing with hash fragments in the URL, #/products/42 and that kind of thing. Almost nobody builds it that way now.
2. JavaScript frameworks
Four names cover most single page application frameworks in use today: React, Angular, Vue, Svelte.
React is a library, not a full framework, and it's the starting point for most React for single page applications work today, with Meta maintaining it directly. It figures out what changed on a page through a virtual DOM and updates only that piece. Plain React is less common now than it used to be. Most teams doing React SPA development build on Next.js instead, since it bundles routing and server rendering that would otherwise mean stitching together separate packages by hand.
Angular for single page applications means a complete package out of the box: TypeScript, routing, two-way data binding, all included. Google maintains it. Enterprise teams reach for it because nobody has to assemble the pieces themselves, and a large team inherits fewer decisions to disagree about.
Vue took a smaller footprint and fewer opinions about state management than either of those two. It's bigger outside English-language developer surveys than inside them. In parts of Asia it's the default pick, not the alternative one.
Svelte compiles down to plain JavaScript at build time. No virtual DOM ships to the browser at all, which is why Svelte apps tend to load lighter than the same thing built in React. Fewer teams use it than the big two, but developer satisfaction surveys keep ranking it near the top anyway.
Ember and Backbone are both still running somewhere, mostly in codebases nobody's gotten around to rewriting. Starting a new project on either one in 2026 would be an odd call.
Choosing between React vs Angular vs Vue for SPA work usually comes down to team size more than any benchmark. A five-person startup team moves faster in React, with its flexibility and enormous library ecosystem, than fighting Angular's structure. A forty-person team scattered across time zones often does better with Angular forcing consistency on people who didn't write the original code. Vue tends to win when the priority is getting someone productive in their first week, not their first month. Businesses that need specialized expertise to build these applications can hire software developers with experience across modern SPA technologies.
3. Ajax, GraphQL, and WebSockets
Ajax pulls JSON from an API in the background, and it's been the default since jQuery made it simple back around 2006. Most SPA data fetching still runs on it. GraphQL shows up more in bigger apps now because REST tends to over-fetch: ask for a user record and get back forty fields when the page only needed three. GraphQL fixes that by letting the client specify exactly which fields come back.
WebSockets keep a connection open in both directions. A chat app needs that. So does a trading dashboard where prices update every second and nobody's manually refreshing to see it. Server-sent events do roughly the same job but one-way only, server to client, and they're less setup work when the client never needs to talk back.
4. Service workers
A service worker runs outside the page, in its own thread in the browser. It can cache API responses and static assets so the app still works on a bad connection or none at all. Airline apps lean on this for boarding passes. Notion caches your last-opened pages the same way. Without a service worker, an SPA is a website that happens to feel fast when the wifi's good and stops working the moment it isn't.
5. Server architecture
Most SPA logic runs client-side now, with the server reduced to an API returning data. That's the standard setup. Some enterprise stacks still keep page state on the server and push rendered updates down to the client instead, but that costs more server memory and scales worse, since every request from a given user has to land on whichever server is holding their session state.
Single Page Applications - Pros vs. Cons
Like most other technologies, SPAs (single-page applications) have advantages and disadvantages. Knowing each will bring you closer to deciding whether the SPA framework fits your app idea.
Pros of Single Page Applications
1. Faster After the First Load: Amazon's latency data is old at this point, but it's still the number everyone cites: every 100 milliseconds of added delay cost them 1% in sales. Run that 1% against Amazon's current revenue and it comes out to roughly $3.8 billion a year. That's the scale companies are actually working with when they talk about page speed mattering.
An SPA loads its shell once, then fetches only the data it needs after that. A traditional multi-page site rebuilds the whole page, HTML and CSS and JS included, on every navigation. Someone browsing a product catalog on an SPA hits one full load and then a string of small data requests. The same session on a traditional site is a dozen full page loads back to back.
2. Frontend and Backend Move Independently: An SPA talks to the backend through an API instead of the backend generating HTML directly. That split lets a frontend team rebuild the UI, swap out a framework, or run a layout test without touching backend code, as long as the API contract holds. Login, checkout, order tracking, all of it keeps working exactly as it did on the backend side while the frontend changes shape around it. It's also why teams building with modern JavaScript frameworks can hire frontend and backend engineers separately and ship on different schedules instead of coordinating every release together.
3. No Full Reload on Interaction: Click through a multi-step form or filter a product list on an SPA, and nothing visibly reloads. That's what people mean by an "app-like" feel, not a vague impression but a specific behavior: no white flash, no scroll position resetting, no re-fetching the header and nav on every click. A static blog barely notices this. A dashboard someone stares at for hours a day notices it a lot.
4. Real-Time Features are Easier to Build: A content editor showing a live word count, or a dashboard updating numbers as new data lands, doesn't need a page reload to show a new state on an SPA. The same feature on a traditional site means reloading the whole page to update one number, unless you're already bolting an Ajax layer onto a server-rendered site anyway.
5. Less Bandwidth After the First Load: Because the shell loads once and everything after that is just data, an SPA typically moves less data per interaction than a site sending full HTML on every click. That matters most on a slow connection, where every request carries real latency regardless of file size.
Single Page Applications Cons
1. Search visibility takes real work: Google indexes SPAs in two passes. It crawls the raw HTML first. Then it comes back later, sometimes minutes later, sometimes hours, and renders the JavaScript to see what's actually on the page. If your content only shows up after that second pass, you're relying on a step you don't control the timing of. One SEO firm audited a SaaS company that rebuilt its marketing site as a React SPA. Organic traffic fell off a cliff, and when they checked Google's cached version of the rendered page, the body was a single empty div for almost every URL.
Outside Google it's worse. ChatGPT and Perplexity's crawlers don't run JavaScript at all right now. An unoptimized SPA is a blank page to them. Server-side rendering or prerendering fixes it, but that's extra infrastructure to build and keep running. It doesn't come free with the architecture.
2. Heavier load on the browser: A traditional site does most of its rendering work on the server before the page reaches the user. An SPA does that work in the browser instead. Older phones and older browsers feel it more. A five-year-old Android phone rendering a JavaScript-heavy SPA is a noticeably worse experience than the same phone loading a page the server already built, even on identical wifi.
3. A wider attack surface: More logic runs client-side in an SPA, and anyone can open dev tools and read it. Cross-site scripting is the main risk here. Unsanitized user input rendered straight into the DOM gives an attacker a way to run a script inside someone else's session. A server-rendered app has fewer entry points for this by default, since less of the logic is sitting in the browser to begin with. API keys and tokens end up in the browser more often too. A compromised script on a server-rendered site usually can't reach much. On an SPA it can reach whatever's sitting in local storage or memory at the time.
Conclusion
SPAs cost more upfront and less afterward. That's the actual trade. A dashboard someone uses eight hours a day gets real value out of never reloading. A five-page marketing site mostly just inherits SEO risk it didn't need to take on.
Server-side rendering closes that SEO gap, but it has to go in from the start. Bolting it on after launch means rebuilding routing and data fetching you already shipped once.
Framework choice comes down to team size more than anything else. React fits a small team that wants flexibility. Angular fits a bigger one that needs structure enforced. Vue splits the difference when the priority is getting someone productive fast.
If you're weighing SPA architecture against a traditional build for your next project, it's worth working through the tradeoffs with a team that's shipped both. Offshore software development services can also provide access to frontend and backend expertise when you need to build or scale an SPA without expanding your in-house team.
Frequently Asked Questions
React, Angular, Vue, and Svelte. React has the biggest ecosystem and the most hiring pool to draw from. Angular ships with routing and TypeScript built in, which enterprise teams like. Vue has a shorter learning curve than either. Svelte compiles away the runtime entirely and ships smaller bundles, but fewer developers know it well.
Team size decides this more than any benchmark does. A five-person startup gets more out of React's flexibility than Angular's structure. A large team spread across time zones usually benefits from Angular forcing consistency. Vue is the pick when someone needs to be productive in their first week on the job.
They can, if nobody plans for it. Google crawls the raw HTML first and renders the JavaScript in a second pass that can lag by hours. Most AI crawlers, including the ones behind ChatGPT, skip JavaScript rendering altogether right now. Server-side rendering fixes this, but only if it's built in from day one.
The browser's History API handles routing without a page reload. Data usually moves through Ajax or GraphQL. Real-time features run on WebSockets or server-sent events. Service workers handle offline caching.
By Mangesh Gothankar
By Ashwani Sharma
By Achin Verma
4.8 out of 5 by
