Multi vs. Single Page Applications
With the place technology is taking in our lives, users have growing needs and expectations of web applications. Web apps are steadily replacing our desktop applications and we see immediate benefits from it. Lightweight and mobile-friendly, they allow us to access our data from multiple devices.
Two major design patterns
When it comes to web development, two major design patterns emerge: Multi Page Applications (MPAs) and Single Page Application (SPAs). Let’s dive into these two patterns to get a better understanding of what they tend to achieve and which you should use for your next project.
Multi Page Application
- There are plenty of resources, best practices, solutions and frameworks available. Meaning it is easy to find developers as most of them will have MPA experience.
- Search Engine Optimization (SEO) is really simple as every request returns the full content. Any crawler would see exactly what the user sees.
- Easy development: MPAs are usually simpler to build as it requires a smaller technology stack.
- Faster initial page load: the page is rendered on the server side before being sent to the browser. When received, the content is ready to be displayed.
- MPAs are usually cheaper to build due to the availability of developers and the use of battle-tested technologies.
- MPAs are slower to load pages. The browser waits for the new content and won’t do anything meanwhile. The more content or complex pages you request, the more the user has to wait for his content to be displayed.
- Tightly coupled frontend and backend: in a typical MVC architecture, the server-side logic is in Controllers and Models, while the frontend is in Views. However, they interact closely with each other as the views need to stay aware of the backend.
- Mobile development: the code cannot easily be re-used for a mobile version of the application. You need to develop a new backend for it or add API endpoints and logic in the existing application, resulting in extra development time.
Single Page Application
SPAs recently emerged and are quickly growing in popularity. We can see them as an evolution of the MPA and AJAX combination. An MPA is perfectly fine for developing a simple application and the introduction of AJAX improves the user experience, but it also adds complexity. SPAs focus on this experience by only updating parts of the pages without rendering it again. This way the responsiveness is increased, which gives mobile users the same user experience as when they are using a native app. You probably already use some SPA, like Facebook, Google Docs or Slack to name a few.
- Results in a very reactive app, and an experience close to a desktop application.
- Reduced usage of the bandwidth: after the first page load only specific data is sent back and forth instead of the entire HTML.
- Decoupled frontend and backend: with a clear separation between frontend and backend, developers can work in parallel and not interfere with each other. The result is a higher speed of development, as Controllers are not attached to any specific Views anymore.
- Mobile development is easier as the frontend code can be reused in some cases (with React Native as an example) and both web and mobile apps can consume the same API’s to fetch data.
- SEO is challenging: bots do not wait for the content to be loaded, meaning they will only see your loading spinner and your HTML shell wrapping it if your content is not pre-loaded.
Server-Side Rendering to the rescue
Frameworks like Nuxt.js or Next.js, based respectively on React and Vue.js, counter some of the drawbacks of the SPA design pattern by allowing you to build your application on the server-side. Once the application is loaded on the browser, it will act like a normal SPA until the next manual refresh of the page. SSR can be done without these two frameworks, but they are definitely worth mentioning.
This type of application is called a Universal Application and solves the following problems:
- SEO: as the content is already present when retrieved after the first request, web crawlers can parse it and see the whole page. In addition to the SEO aspect, SSR solves the social sharing issues SPAs have with the OpenGraph system (only one type of metadata as you deliver a single page). These tags can be contextualized with the pre-populated data on the server side.
What about a hybrid app?
One could consider using a hybrid approach, so we would have an MPA application using SPAs for some pages. Although it has some popularity, for example with Ruby on Rails implementing React components, it could potentially combine the disadvantages of both patterns:
- Frontend and backend are intertwined again, preventing the backend to be reused for mobile applications.
- It is a more complicated development, as two frameworks will be used.
- Slower page loading: the content will be rendered on the backend and the frontend framework needs to be loaded on the browser.
What should you use?
So, should you use an SPA or MPA for your next project? There is no perfect solution and the choice between the two is mainly based on the goal of the application. Each solution has pros and cons. MPAs are still incredibly useful for simple projects with short deadlines, SEO management, tried and tested security features. Single Page Applications provides a “snappier” user experience and a code reusability.
To find the solution that fits your project best, you must first define the ultimate goal of your application. Both approaches are scalable and can reach high performance when correctly implemented, but the best choice becomes obvious when the project includes a mobile application or when you want to focus on SEO.
This article is written by developer Steven.