What is a single-page application?
A single-page application (SPA) loads the HTML shell once and then takes over navigation, rendering and data exchange entirely in the browser. The server only talks to the frontend through APIs — the result is smooth transitions without page reloads, immediate feedback on interactions and an app-like experience in the web browser.
This architecture inevitably brings more complexity to the frontend: routing, state management, validation, caching, internationalisation, security — tasks that used to live on the server now have to be implemented in a structured way in the browser. That is exactly what frameworks like Angular, React and Vue were built for: component models, declarative templates and mature tooling.
A well-built SPA is therefore more than a layout in the browser — it is a decoupled application with clear responsibilities, testable components and a deployment story that supports CDN-based delivery and scaling.
User experience
Smooth transitions, immediate interaction, no full page reloads — the familiar feel of native apps inside the web browser.
Separation
A clear boundary between frontend and backend through API contracts — both sides can be developed, tested and shipped independently.
Components
Reusable, tested building blocks — from date pickers to dashboard widgets. Design systems become directly expressible in code.
Delivery
Static builds, cache-friendly, fast initial loads, easy to scale via CDN.
SPA frameworks compared
In the enterprise space we primarily build with Angular — on request and depending on the architecture we deliver in React or Vue as well.
Angular
Full framework · TypeScript · since 2016Google's enterprise framework. Fully in TypeScript, opinionated, with built-in dependency injection, RxJS for reactive streams, a mature CLI and a clear best-practice line. Structures large applications where multiple teams work in parallel.
When to use
Our default in enterprise and public-sector projects — where clear conventions, long-term maintainability and team scaling matter most.
React
UI library · since 2013Strictly speaking not a framework but a UI library. Very flexible, with a huge ecosystem (Next.js, Remix, React Query, Redux) and JSX as declarative syntax. Requires more architectural decisions than Angular, but offers an easier entry.
When to use
When an existing React ecosystem is in place or when specific libraries (e.g. Next.js for SSR) are required.
Vue
Progressive framework · since 2014A middle ground between Angular and React: a complete framework stack (Vue Router, Pinia, Vue Test Utils) with a gentler learning curve. Templates instead of JSX, very readable single-file components, compact footprint.
When to use
When teams want a pragmatic middle ground or existing Vue applications need to evolve.
The browser as an application platform
Beyond frameworks, two browser technologies have established themselves as extensions to frontend architectures — particularly when reuse across framework boundaries or compute-heavy logic in the browser matter.
WebAssembly
W3C standard · since 2017A binary format that runs near-native compiled code directly in the browser — with performance close to native applications. Relevant when compute-heavy logic should move into the browser or existing code from other languages should be reused.
In practice
With Blazor WebAssembly, .NET components and C# code can run directly in the browser — without a JavaScript bridge. For organisations with a substantial .NET codebase this is a natural extension into the frontend, with no language switch required.
Web Components
Browser standard · since 2018A bundle of web standards (Custom Elements, Shadow DOM, HTML Templates) that allow building reusable UI elements that work across frameworks. A component can be used equally in Angular, React, Vue or plain HTML applications.
In practice
Shipping company-wide design systems as Web Components so that different teams using different frameworks can use the same UI building blocks — without a dependency on a specific frontend stack.
Experience and AI-augmented development
In the Tenvias core team and at our development partners we have engineers who have helped shape the shift from jQuery through Backbone and AngularJS to modern Angular, React and Vue. That depth shows in architecture decisions that still hold up in five years — and in migrations from legacy stacks (AngularJS, jQuery apps, early single-page frameworks) that survive in production.
In the enterprise context, frontend work means more than pure UI engineering: accessibility (WCAG/BITV), multilingualism, authentication via identity providers, secure API integration and embedding into existing design systems. We plan for these from day one.
As in our backend work, we have been applying AI-augmented development tooling systematically in frontend projects since 2024. Component boilerplate, test generation, Storybook stories, migrations across framework versions — all of this accelerates considerably without compromising quality control.
On standardised implementation and migration work we see speed gains of 30 to 50 percent. Responsibility for architecture, accessibility and API contracts stays with the engineer — AI-generated code goes through code reviews, tests and the CI pipeline like any handwritten code.
