An Overview of Modern Web Application Frameworks

Multi-page application, single-page application, and other design choices

Kelvin Yan



Web technologies evolve fast.

Web applications, referred to as web apps for short, play a crucial role for businesses in today’s hyper-competitive world. Companies should strive to make users love using their products and services. Web apps give dynamic user experiences.

Web application frameworks work to simplify development of web applications. They provide core functionality to work from so applications do not need to be built from the ground up. They help companies save time and reduce costs. They are easy to customize and output pages with dynamic content.

What exactly is a web application?

Sometimes it is difficult to distinguish between a website and a web application. Not every URL can be clearly classified as one or the other. To put it simply, a website is intended for display purpose only. A web application is also a website, yet it allows its user to do much more — such as to take input and do computation, allow you to edit an image, or send a message to another user; Web applications are defined by its interaction with the user.

People enjoy using web apps because they are customer ready and do not need extra software installation — only a web browser. This is especially important for them before they have even decided on which app to use.

Need for web applications

Businesses use the Internet to broadcast their brand name, products, and services to the world. They constantly launch and update new web products because the Internet is growing at an amazing rate year after year.

While determined to keep up with new and upcoming trends and competing to win over customers, there is always a drive to expand their e-commerce and cloud service functionalities.

As changing demands fueled the need for new features that make it effortless for customers to enjoy, websites grew in complexity to meet these challenges. 

First-movers such as eBay and Amazon succeeded not only because they had strong marketing teams. Other companies had strong marketing teams too. They capitalized on the fast-evolving market with highly functional web applications.

They took simple concepts, such as purchasing, inventory, and transactions, and created scalable web marketplaces that are so dominant today.

Web applications that served different needs, such as Hotmail or Gmail cloud email services, leveraged the web browser capabilities to create email applications that did not require software installations. This portability is one reason they have grown into what they are today.

User authentication, profiles, real-time data tracking, messaging, online payments, app state — these are some ubiquitous features you see today. It is harder to release a successful web app if it is lacking in too many features that other web apps commonly have.

It is important to focus on the core features and functionality when developing a web app, but it is not enough to simply focus on those core things. An equal amount of effort should be spent on other features to complement the core functionality to make users love your product.

Web application frameworks continue to gain in popularity as new companies enter and create applications of their own to grab market share. Frameworks provide a base for much of the core functionality that every web application requires.

Almost all new web applications use at least one framework to simplify development and to keep up with change. 

Framework types

There are many programming frameworks available to develop web applications from – several are listed in the sections below. They are divided into 2 main types: Multi-page applications (MPAs) and single-page applications (SPAs).

Multi-page applications came first and employed traditional programming languages such as PHP, .NET, and Java. MPAs are applications that run on a server and can communicate directly to databases.

Single-page applications gained traction when cross-browser JavaScript support improved. This also happened around when the usage of a popular browser plug-in, Adobe Flash, lost favor and died down. Unlike MPAs that live on the server, SPAs are downloaded to the client browser a single time and the page does not need to reload again. With a SPA, you still need a back-end server to provide content from APIs, but there is greater separation between both layers. The front-end view layer and the back-end server layer can each be swapped out without affecting the other so long as they both use the same API contracts.

How to choose MPA or SPA

MPA and SPA each serve to provide solutions to complex problems. One of the key advantages a SPA has is giving the user a faster and smoother experience. On the other hand, an advantage for MPA is that optimizing for SEO is easier and you can deal with application state on the server.


A typical MPA serves a brand-new page on each route change and every change in data. Back when JavaScript support was not as ubiquitous and cross-platform, MPA was often preferable. Older computers did not have the same processing power as they have now, so it made more sense to process on the server. MPA generates fully ready to render HTML pages from the server1. The browser only has to receive the HTML mark up and then draw the page for the user. 

1 this is a somewhat generalization as MPAs can also use JavaScript to dynamically render certain portions of the page.


With a typical SPA, an empty shell of the application is delivered to the client on the first request, along with JavaScript files which initialize the application in the browser. The client’s device then fetches data from API endpoints to populate content inside the application as the user interacts with it. This allows them to be far more efficient and consume less data when compared to an MPA which generates a full page on each action. SPAs use built-in web browser functionality that allow unbroken transitions as the user navigates the web app. This way, clicking on links and buttons feels more like an application than a web site.

If speed and smoothness is imperative for the application, using a SPA framework would be the obvious choice.

If search engine indexability (SEO) is more important, then development and operational complexity will be reduced through the use of an MPA. This is because a SPA is only served with an empty HTML app shell — it requires the web crawlers to do some lifting and execute JavaScript files to determine what the content on the page is. Not only is this cumbersome for crawlers, it increases the time taken to render the page which may, at least with Google Search, impact your index rankings. We go more in depth on how to solve SPA indexability issues later. 

Single-page applications are everywhere

Web applications have become necessary for companies to win customers, and single page applications provide the smooth experience that gives a competitive edge with getting users to stick to their product.

SPAs are developed in JavaScript or one of its supersets. MPAs use back-end languages (such as PHP, .NET, Java, or Python).

SPAs are modern and are an ideal choice for internal company applications and customer facing sites. Common websites such as Twitter and Facebook use SPA.

Some examples of SPAs which contain complex interactivity include G Suite, Microsoft Office 365, Azure, and Digital Ocean.

Modern single page application frameworks

The most popular SPA frameworks right now are Angular, React, and Vue. Other SPAs include Ember and Meteor. There is no clear winner for which SPA framework is better, but important factors include design of the system and developer comfort and experience with the framework.

Are SPAs fitting for your web application?

SPAs are great because they will seem faster for the user. Sometimes though, there are drawbacks to using this modern web app type. Here are reasons why it may or may not be the right fit.

Why a SPA is a good fit:
  • Gives an experience similar to a desktop or mobile app
  • Creates greater separation of the back-end layer and the view layer
    • Building data endpoints instead of server-generated pages allows greater flexibility and reusability
    • Your data can be consumed by different applications where re-using API endpoints would make better sense
  • After the initial load and start up, everything is fast
  • Scales better because of the lighter load on web servers
  • SPAs can be ported into hybrid native mobile apps
Why a SPA might not be the best fit:
  • SEO is important
  • MPAs will usually have a view-templating system built into the framework that can be easier to develop with
  • Your web application is simple and only has a small set of functions
  • Large SPAs can often be more complex to build

Hybrid apps

Sometimes there will be certain modules or areas of an application that can be separated. A hybrid mix of SPA and MPA can be made to work in tandem using web server redirection.

Alternatively, SPA and/or MPA can be mixed with static web pages. Static web pages will always load faster than their counterparts. They are a good choice on pages which only provide information and do not change often (i.e. info and blog pages).

Solving SPA indexability

Some SPAs deploy an additional engine to deal with SEO related issues. They call this feature server-side rendering (SSR). Server-side renderers are middleware that draw content into the app shell before the HTML markup is sent to the client. By default, SSR are added features and are not built into the frameworks. Implementing SSR will always increase the complexity of your application. 

SSRs can sometimes be fickle. A small example based on personal discovery — a SSR for the Angular framework (Angular Universal) does not pre-render certain meta tags such as Open Graph that might be very important to your app. This would affect how WhatsApp previews would look like to users sharing app pages to their friends.

SSR can work for you, but usually contains quirks and requires additional effort to optimize for. 

That being said, some amazing services such as Prerender and Rendertron solve this problem, even the WhatsApp previews. These services act as a caching proxy (they serve rendered content rather than just the app shell) that facilitate web crawlers and previewers to understand the content. This also can improve technical SEO for SPA pages because they are cached and do not need to wait for the SSR to do work on each request. 

Many MPA frameworks to choose from

Common MPA frameworks include Java Spring, Python Django, ASP.NET MVC/Razor, and PHP Laravel. When not serving pages, they can also act as the API back-ends for SPA frameworks to consume.

Modern multi-page application frameworks

Hybrid MPA and SPA

There is no single best solution where you might build the entire site with a single framework. Oftentimes, and if resources are available, a hybrid approach of SPA and MPA and/or static pages works best if the web application can be divided up. Both choices, whether it be a SPA or MPA, will work for the company. The differences are in the implementation details and user experience.

It may sometimes be more complex to build a SPA, although any large application will undoubtedly be complex anyway.

Do you need a SPA or an MPA? Which one is better?

If you want your web app to function similar to a desktop or mobile app, have fast navigation between pages, have seamless transitions, then it would be a great idea to implement a SPA.

On the other hand, if you require a database but there are few interactions between your user and the application, then it may be easier to develop and deploy using a MPA.

Most companies have adopted SPAs or are in the process of converting their web app to a SPA because companies want to build the best product and provide the best user experience that will make customers stick with them.

In 2019 the overall experience for users is that web apps are noticeably faster than in the past. It is uncommon now to see large enterprises or startups build their web applications as a MPA.

Native apps

As an aside, there exist many native apps that provide next to no additional functionality over a web app except being able to have a shortcut icon on a device. If you are thinking about developing a native app, you should also consider whether or not a web app would suffice. A web app will never match the full range of capabilities that a native app has and will not be able to use the full screen pixel dimensions of the device, but it will allow for simpler cross-compatibility between all devices. Furthermore, some users may look elsewhere if they need to download and install an app to try it.