-
-
Notifications
You must be signed in to change notification settings - Fork 6
SPA vs MPA
Web development has evolved significantly over the past two decades, leading to the rise of different architectural paradigms. One of the most popular architectures that has emerged is the Single Page Application (SPA).
The concept of an SPA is that it downloads all of the application code in its first request - generally within index.html - and then heavily relies on JavaScript to hook events to all links and forms, so the browser never actually navigates away from the page. Instead, the browser re-draws areas of the page only when they need to be updated. This creates a smooth, fast, and modern application, and has become a staple development methodology of many front-end frameworks like React, Angular, Vue, and Svelte. A downsides is that downloading everything within a single page makes the initial page a lot slower.
The data that drives a SPA's functionality can be supplied to the front-end via an API, using background HTTP calls. Generally, this means the browser can update the state of the view extremely quickly, and load data in the background to create much faster, slicker applications. A downside is that search engines or accessibility users can't access the information within the pages.
The way SPAs operate is effectively loading a runtime - or basic operating system - into the browser, that loads and runs your application code. This "runtime" has to implement the functionality defining what happens when every link is clicked, or when every form is submitted, or how a visually impaired person uses the application via a screen reader, for example. It turns out that there are a lot of nuances to application user interfaces, and what a SPA has to accomplish is not a trivial task, and has a lot of room for errors and mistakes to occur.
Because the browser never actually navigates between pages, all of the application's state has to be handled within the single page. JavaScript is usually used to update the browser's URL bar to represent the state of the application, but a common downside of SPAs is that the application's state becomes out of sync with the URL. Large applications can be difficult to debug, as there is a potential for application logic to become distributed amongst
All of the downsides of SPAs can be solved - generally by adding more code to solve the problem.
However, SPAs contradict the core principals of WebEngine as it is possible to gain the benefits that come with an SPA without having to change the way the web was designed to work - websites with multiple pages.
A WebEngine application is built as a Multi Page Application (MPA), where each page has its own individual HTML and PHP file - but by using progressive enhancement, MPAs can have all the benefits of SPAs without any of the complexities or downsides.
Progressive enhancement is a web development approach that prioritises making a website or application accessible to everyone, regardless of their device or browser capabilities. It starts with a basic, functional version of the site using simple, reliable technologies like HTML and CSS, ensuring that all users can access the core content and functionality. Then, additional features and enhancements are added on top for users with more advanced browsers and capabilities, often using JavaScript and more complex CSS.
This way, the web application can be built using simpler technology, it works for everyone, but provides a richer experience for those with better technology.
MPAs can take advantage of 30 years of tried-and-tested technology, with no need to fix nuances that were solved in the web platform decades ago.
MPAs maintain a clear separation of concerns with a single, predictable entry point for each page. This enhances code readability and maintainability, making it easier for developers to understand and manage the application logic.
In WebEngine applications, this is further enforced by using go
and do
functions to indicate the entry point of the application logic.
// TODO: Mention turbo, and other document updating techniques.
Website | Packagist | CircleCI | Scrutinizer
- Request-response lifecycle
- Running your application
- Project layout
- Application architecture
- Web servers
- URIs
- Page view
- Dynamic URIs and pages
- Headers and footers
- Page logic
- Protected globals
- User input
- Cookies
- Sessions
- DOM manipulation
- Custom HTML components
- DOM templates
- Binding data to the DOM
- Database
- Client side assets
- API Webservices
- Security
- Configuration
- Build system
- Coding styleguide