An SPA is a web application or website composed entirely of static web resources such as HTML, JavaScript, and CSS, loaded just once into the web browser in a single page load. Once booted, it updates itself intelligently as the user starts interacting with it. Unlike traditional web applications that perform a full page refresh for screen navigations, SPA routes and redraws (re-renders) screens without reloading the whole page (or the next page) from the server. It reconstructs the DOM structure with the help of JavaScript and styles itself with CSS in response to user actions and application events in order to represent them on the screen.
After the initial boot, the only time an SPA confers with a server is for dynamic data. SPAs usually rely on AJAX or WebSockets for data access from the server. The data transfer format is mostly JSON and sometimes XML. They contact the server via AJAX over HTTP asynchronously behind the scenes; this gives a smooth, fluid user experience without blocking the screen or keeping the user waiting for server responses. Besides, the server can synchronize its data changes with the client using the WebSocket API to provide a real-time experience.
Besides the massive productivity gain and prominence of frontend developers, SPA offers many architectural benefits. It is blazingly fast compared to traditional server-rendered web applications, since it works entirely locally to the client. SPA offers a much more smooth and fluid user experience because of its immediate response, without needing us to resubmit the entire page to the server on every user interaction.
SPAs offload the responsibility of the entire application state to the browser, freeing up server resources to focus on the core business logic (service) and data in terms of stateless web services, often designed as REST APIs. With SPAs, the server just becomes an API server; the entire user interaction is handled by the client, which improves server scalability a lot.
Another advantage, probably the most important one of SPAs, is that both client and server applications can be designed and evolved independently from each other. You can replace either of these without affecting the other as long as the endpoint (API) contracts remain intact. Also, you can let frontend developers build the UI and backend developers provide the data; both teams can focus on their own domain while working around a data contract.
Developing an SPA in plain JavaScript is not a smart idea considering the magnitude of responsibility handled by the SPA paradigm. It would be extremely tiring and error-prone if we set out to write all the routing, data binding, screen authoring, and rendering code from scratch in our applications. Fortunately, a set of very impressive frameworks emerged out of the SPA concept. Each of them offers varying levels of abstraction and architecture styles; some of them use powerful templating technologies. Let's take a look at the most popular SPA frameworks:
In this chapter, we will use Ember.js for building an SPA that works as the frontend for a Spring API server. We will explore Ember.js, its core components, and the development tools first and then develop the frontend application using Ember, connecting to a Spring-based API server on the backend. This chapter will make you a full-stack developer with both server-side and client-side skills on the modern technology stack.