In this article, I’m going to set aside all the hype that surrounds the tech and evaluate it objectively. I’ll list the advantages and drawbacks of the SPA approach as well as suggest when to use it.
Table of contents:
- SPA vs MPA. What’s the difference?
- Advantages of SPAs
- SPA Drawbacks (and how to fix them)
- So what’s the verdict?
When MPAs react to your input or has to display some new content, it requests a new HTML page from the server. After receiving the markup, the browser renders the new page causing it to reload.
When you interact with an SPA, your browser makes an AJAX call to the server. But instead of rendering a new page, the server can just send you the data (usually in a JSON format). The SPA will then use that data to render some parts of the page directly in your browser.
The result is an application that consists of a single highly-interactive web page that never completely reloads.
So now you know the basic difference between SPAs and MPAs, let’s dive deeper and discover their advantages and drawbacks.
1. Fast and smooth UX
It’s easy to imagine how constant full-page reloads can hurt the user experience.
This decreases the server-client traffic and makes the app feel “snappier”.
With the traditional applications, the server has to generate complete pages for thousands of users. But with SPAs, the rendering is done on the client-side. This means the server responds much faster to user requests.
So as long as you don’t use horribly outdated hardware, SPAs are much faster and responsive than traditional web applications.
This makes them the ideal candidate for porting old desktop apps and enterprise-grade solutions to the web without altering their UI and workflow.
2. Local caching and offline functionality
After the initial request, single page web apps cache all the data they receive from a server and store it locally. This way, SPAs can continue to function even if the Internet connection fails.
When the application connects back to the network, it synchronizes the local data with the server and restores the full functionality.
You can also partially forgo using cookies in favour of Web Storage. Although pretty similar in function (tracking users, their settings and preferences), local storage can store more data (5MB vs 4KB per cookie).
3. Perfect Mobile Adaptability
By the end of 2017, the mobile Internet speed remains almost twice as slow as its fixed counterpart. At the same time, users are all too eager to abandon slow apps. So it should come as no surprise that mobile users would benefit the most from apps that load faster.
Moreover, single page applications are significantly easier to port from web to mobile. You can generally use the same backend code both for the web and iOS/Android versions of your app, which is quite rare with the traditional approach.
And finally, compared to MPAs, single-page UI is much closer to that of native apps. This means you won’t have to change much design wise when adapting your SPA to mobile.
4. API reuse
It’s also much easier to create an SPA if you already have a mobile app. If the app communicates with some APIs on the server-side, you can likely reuse the same APIs in your web application without significantly altering them.
And visa versa, if you’re planning to launch a native app, the APIs you’ve written for your single page web application will come in handy when you start the mobile development.
5. Streamlined development
Single page application development is similar to building a house with LEGOs. Once you’ve got the components (LEGO bricks), you can quickly construct the SPA without the need to add the same code fragments over and over.
Also, you don’t have to write custom code for rendering HTML pages on a server. And it’s much easier to initiate the development from a file://URI as you don’t need a server at this stage.
Finally, SPAs are significantly easier to deploy and version in production.
6. Back-end/front-end separation
In single-page applications, UI is separated from data. This allows you to revamp your frontend and alter the UI as much as you want without affecting the backend (barring some static resource files).
Decoupling of front-end/back-end development makes it easier to find bugs in your codebase. It’s also easier to integrate new APIs and alter the ways in which data enters the SPA framework and flows to different systems. All without affecting the UI.
7. Painless Chrome debugging
It’s much easier to debug single-page applications with Chrome. You can see the whole code at once, observe the network operations and inspect page elements together with the associated data.
Source: Chrome Web Store
1. SEO issues
As a result, single-page applications rarely made it to the top of the search results.
Still, Google admits it sometimes can’t properly index single-page applications. Not to mention that other search engines haven’t yet achieved the same SPA-crawling prowess.
Search engines crawling SPAs created with various JS frameworks. Source: moz.com
Another SEO issue comes from the fact that SPAs have a limited semantic kernel when compared to the traditional applications. This originates from the fact that it’s simply impossible to stuff as many keywords into a single page website.
To solve this problem, choose your content to better match the user requests. Also, take advantage of meta descriptions, tags, and internal anchor text links. Or you can dedicate your SPA to a single subject as Google gives higher rankings to thematic sites.
Finally, you may run into some shareability issues as Facebook’s bots are hilariously bad at crawling SPAs.
2. Memory leaks
Event listeners used in SPAs can cause a loss of available memory on the user devices. Since your app is essentially a single page that never reloads, memory leaks get worse the longer SPA runs.
If you don’t pay enough attention to this problem during development, it can lead to significant slowdowns and quickly drain the device’s battery.
3. Security issues
Cross-Site Scripting (XSS) makes SPAs a bit more vulnerable to hacker attacks. XSS allows trespassers to insert malicious client-side scripts into otherwise trusted applications.
But there are ways to combat Cross-Site Scripting. With single-page applications, you can secure your data endpoints and separate the JS that gets downloaded by a client into multiple isolated pieces.
This way, attackers won’t be able to access all your code at once.
4. Slow first load
SPAs launch slower than the traditional applications. This happens due to client-side rendering. Before your browser can render the page, it has to load bulky JS frameworks. This could take a while, especially for the large application.
But after the first render, SPAs become much faster than MPAs.
Fortunately, there are ways to speed up the SPA initialization such as loading assets dynamically and minimizing the scripts.
The partial solution for this problem is to use server-side rendering for the first load. Still, some of your app’s functionality may remain unavailable with the JS disabled.
Devotiondress, an SPA that works with JS disabled
6. Poor app scalability
With the traditional approach, the application’s functionality is spread over multiple pages. You can gradually add content and expand the pagecount. It’s also relatively easy to alter a part of your MPA without affecting the other pages.
If you want, for example, to change the application’s framework, you can do it page by page until the whole MPA is redesigned.
In SPAs, the business logic is built into the separate components that are easy to develop and maintain.
But making changes to the app’s architecture is a whole other story. A single feature may consist of several components and altering a commonly used element can affect other parts of the application.
That’s why you have to take into account the future changes to the SPA’s functionality during the planning stage. If you have a clear vision of where your application is heading, the developers will be able to factor in the possible changes before the architecture is set in stone.
7. Navigation issues
In SPAs, back and forward buttons have some unexpected behavior.
Instead of returning you to the prior state of the app, the back button can actually load the previous page (which can lead you to a completely different website).
When you press the back button, the app may also lose the scroll position so you end up on a different part of the page.
In some SPAs, you can’t even open a link in a new tab, refresh a page, or bookmark it.
Fortunately, you can fix the navigation issues with HTML5 History API that is already bundled with the majority of JS frameworks.
8. Weird behavior due to asynchronous requests
SPA manage user requests asynchronously and this can lead to some unexpected behavior.
When you press a button or click a link in a traditional application, it will stop all current activity and make a new request to the server.
But in SPAs, the server responses come asynchronously. This means they can arrive not in the same order as you’ve requested. So if you click several links really fast, you can end up on the wrong page. Or you may experience graphical glitches if you press the same button several times.
Your developers will have to write code specifically to handle such situations.
Now you see why single page applications became so popular recently. But before you pick your side in the SPA vs MPA debate, consider what you want to achieve.
If you aim to offer multiple services or different categories of goods, then creating a website with multiple pages is the logical solution. That’s why enormous applications like Amazon are built this way.
MPAs are also a good idea for websites that have a lot of content (such as news portals) and require flawless SEO.
If you, instead, wish to focus on promoting a single product or service, SPAs are a way better solution. They allow you to pack impressive functionality into a lightweight application. The superior UX makes SPAs ideal for porting highly interactive desktop applications and creating native-like experiences on the web.
That’s why CRM/ERP systems and interactive dashboards in SaaS products are often built as single-page apps.
All in all, SPA is an awesome tech. It offers many advantages and you can easily overcome its few cons with a qualified development team.
That’s why MindK recommends going the SPA way for the majority of our new clients.
So if you have trouble picking the right approach, you can always contact us and discuss your project.