When to use Multi-Page Apps?

When should you choose MPA over SPA? While Single-Page Applications (SPAs) are conquering the world, we … Read more When to use Multi-Page Apps?

When should you choose MPA over SPA?

While Single-Page Applications (SPAs) are conquering the world, we still have use-cases for Multi-Page Applications (MPAs). One scenario is for large e-commerce applications like Amazon and eBay, where they stick with MPAs for different reasons.

This article will help you choose between MPA vs SPA and the right JavaScript framework to meet your architecture constraints.

Multi-Page Applications

As its name suggests, MPAs consist of more than one page.

With MPAs, any data change or transfer to the server results in either a new page or a site reload.

Typically it’s dependent on Server Side Rendering techniques for better page loading times. However, to choose MPAs over SPAs, we should first understand the difference between how these two operate.

Single Page Applications vs Multi-Page Applications

The below diagram shows what happens throughout the lifecycle of both these application types.

The Life Cycle comparison of MPA and SPA

In MPAs, the entire page reloads per request, whereas in SPAs, only the required data is retrieved in JSON format initiated by JavaScript.

Why and when should we choose Multi-Page Applications?

Even though SPAs are common nowadays, there are issues with search engine optimization (SEO), browser history management, and handling security issues concerning JavaScript execution. As a result, there are instances where an MPA becomes a better choice.

1. SEO

MPAs have a better Search Engine Optimization capability than SPAs because we can optimize each page to a particular keyword by inserting meta tags and rendering content.

As a result, with search engine crawlers, MPAs usually rank better.

2. More insights over the website

MPAs can get more insights from analytical services like Google Analytics compared to SPAs.

In SPAs, it’s harder to figure out which part of the application is not performing well, and we can only get general data like the visitors and how long they stayed on the website.

However, in MPAs, we can quickly draw insights and valuable data about each page since they are naturally separated from each other.

3. Easily scalable

The high scalability of MPA is essential when it comes to complex and large websites. Since there are no page limitations, you can develop and release new content pages with the least impact on the existing code.

This resembles the usage of MPAs in large e-commerce sites, where SEO and scalability dominates.

4. Websites with different entry points

MPAs work well for websites with different entry points where users might visit only a subset of pages.

In this case, having lightweight pages are essential instead of loading a mandatory set of JavaScript files upfront.

5. When requirements like embedding exists

Sometimes, we need to facilitate the embedding of pages on other websites. Since we have no idea where they end up (browsers, mobile apps &, etc.), using multiple pages focused on embedding works better.

Besides, we can optimize the particular page with minimal dependencies and server-side rendering to address a wide range of audiences.

JavaScript Libraries, Frameworks for Multi-Page Applications

There are many frontend development libraries, frameworks and tools that we can use to build MPAs. However, since MPAs primarily utilizes a server-side framework like ASP.NET (C#), Spring Boot (Java) or Django (Python), we must choose a frontend library or framework aligning with that.

Frontend libraries and frameworks

However, the good news is that most of the frontend libraries and frameworks today can be used to develop MPAs. Some of the popular ones are;

  1. Next.js
  2. React
  3. Angular
  4. Vue.js
MPA libraries and frameworks

So now, let’s see how to choose a framework that works best for your application.

As we discussed above, we have many libraries and frameworks that we can use when building MPAs. However, in my opinion, React or Vue.js would be the best to build an MPA for the following reasons.

  • Both are lightweight and fast.
  • Both can be used to develop beautiful User Interfaces.
  • Both are view engines at the core. Therefore, can organize the code into web components, allowing us to build a simpler code without clutter or duplication.

On the other hand, using Next.js or Gatsby would be an all-in-one solution for public-facing applications.

So, if you are starting with MPAs, I would highly recommend considering Next.js or Gatsby, which handles the entire lifecycle of the MPAs.

However, none of the modern frontend frameworks such as Angular and Ember.js has any restrictions against MPA development. But, you have to handle several things like SEO rendering & etc. using a custom solution.

Above everything, don’t forget to pick a library or framework that matches your requirements.

Build with independent components, for speed and scale

Instead of building monolithic apps, build independent components first and compose them into features and applications. It makes development faster and helps teams build more consistent and scalable applications.

Bit offers a great developer experience for building independent components and composing applications. Many teams start by building their Design Systems or Micro Frontends, through independent components.
Give it a try →

An independently source-controlled and shared “card” component. On the right => its dependency graph, auto-generated by Bit.


In this article, we discussed important quality attributes of MPAs, some of the best libraries and frameworks available, and things to consider when selecting a framework to build an MPA.

So I hope you all got a good understanding of the subject. Feel free to use the comment section for any suggestions or questions.

Thank you for reading!

Learn More

When to use Multi-Page Apps? was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Bits and Pieces

Leave a Reply

Your email address will not be published. Required fields are marked *