- ★
- ★
- ★
- ★
- ★
Web Development
Single-page application vs Multi-page application.
In this post, I’ll try to shed some light on an area where I still see confusion and a lack of clarity around the topic among budding developers, particularly those who are new to web development. My first objective is to clear up some uncertainties around the terms, the technique, and on the naming facade.
Confusion A: Website vs web application
Before explaining the difference between single-page and multi-page applications, I will address one of biggest causes of confusion. Consider the two titles below.
- Single-page application vs multi-page application
- Single-page site vs multi-page site
You’ve doubtlessly spotted the difference. A single-page applications is not synonymous with a single-page site. And a multi-page application is not synonymous with a multi-page site. Today’s topic is on the former: applications.
The reason I bring this up is, it’s a classic false equivalence made by new learners or developers in the early stages. There is a mammoth difference between a site and an application.
Websites generally involve one-way traffic or one-way information feeds. Viewers do not have much – or very limited – interaction with websites and cannot meaningfully communicate back to them. Websites are navigable, be it to another section of the page (in case of a single-page site) or across to a different page (in case of a multi-page site) and contains digital contents such as text, images, video, audio, and so on. Websites of either kind are mostly static, meaning the content doesn’t update dynamically, also there is limited scope for user interaction. This is not so say that a website cannot have data coming from database or a user cannot interact with a website, but that any interactive features are usually very limited & generic: for example a user login, contact form, Google map, subscription form, or search box.
A distinctive feature of applications, on the other hand, is their sheer "interactivity". Web applications give users the option not only to receive information but also to respond to, alter or manipulate the information: that is, to engage in a dialogue with their contents and the business. A web application such as an online shop, for example, allows a given user to place an order, cancel an order, check their order history, update the order, add or delete payment and contact details, contact the seller, and leave comments, feedback or a rating. Social networks are a prime example: each is a self-contained ecosystem in which users can blog, chat, customise, set preferences, share content and interact with others through games, messages and comments.
Another key feature of web applications is "authentication", a process that involves a visitor entering user data to gain access to the system and its available features. This is a vital process for web applications as they require the personal data of the users/consumers in order to function – and monetize. Authentication is also pivotal for security, and to prevent the unauthorised access and theft of users’ personal data.
Because websites and web applications can both be accessed using a browser, most end-users can’t spot the difference and for their purposes, the difference is immaterial. An online shopper believes, they are on an e-commerce website and has no reason to care otherwise. But for the developers it’s a whole different story. That e-commerce “site” is actually a web application – or even a combination of both.
Websites generally are static by nature, and a group of interlinked webpages, which exist on a domain and it’s main goal is to feed information to a user. Web applications are software programs or services that a user can also access using a browser, but web applications are generally created using combinations of client-server programming languages or using web application frameworks. Their main goal, by contrast, is to interact dynamically with users and respond to their requests.
Confusion B: Single-page site vs multi-page site:
Most single-page sites feature a navigation bar, with its items anchored to different sections of the same page. These single-page sites are most popular on landing pages and portfolios, particularly in situations where there is less content to share. For example, if the site being built is for a one-time event, such as an event, festival or wedding, there’s no need to overload viewers with information spread across multiple pages. So as long as all the important information is there on that single page, your viewers are happy.
The same goes for portfolios. You could create an online portfolio across multiple pages, but presenting all the key information on one single page might help your would-be recruiters or clients to find what they want faster. So single-page sites are good where there is a narrow or specific focus.
On the other hand, you might go for a multi-page site when there is going to be a mass of content spread across several different pages with different contexts. But either way, both single- and multi-page websites are static in nature, and cannot be considered as web applications.
Here are two demos I made for demonstration as single-page and multi-page site.
Confusion C: Single-page application vs multi-page application:
There’s a prevailing belief that the idea of single-page applications was conceived around 2003. In fact, the stage was set as early as 1999. Big vendors began to develop techniques to give their websites a “desktop” look and feel and allow users to avoid refreshing the page. Around this time, AJAX (Asynchronous JavaScript and XML) was developed, and for the first time allowed page content to change dynamically without the need for a reload. This saved a great deal of network transfer time and redundant data exchange, as only the required data would be requested of the server, and designated sections of the page would only be updated with the new data returned by the server.
By using AJAX, web applications could communicate with servers asynchronously, meaning they could send and retrieve data from a server asynchronously, unobtrusively (that is to say, in the background), and without interfering with the display and behaviour of the existing page. By decoupling the data interchange layer from the presentation layer, Ajax allowed web pages and, by extension, web applications, to change their content dynamically. Since the days of XML, a more powerful data exchange medium, JSON (JavaScript Object Notation) is now used for data exchange with faster responses time.
Multi-page (traditional) architecture
Single page architecture
As single-page applications began to gain popularity, numerous JavaScript frameworks & libraries emerged, such as Angular, React, Vue.js, Ember.js, Meteor, Node.js. That being said, you can still build a single-page application using vanilla JS (plain JavaScript). If you want, you can also load jQuery, because jQuery has AJAX functionality and as such, it has cross browser support.
Here are two demos I made for demonstration as single-page and multi-page application:
A web application on country details. On this application, I’m using an open-source country database and typeahead.js, so that when you start typing the name of the country into the box it will provide a series of automated suggestions for countries. On choosing one and pressing enter, the application will then request an open-source API to fetch the country details such as name, capital, flag, latitude and longitude. It then sends the latitude and longitude co-ordinates to the Google Map API to generate the map. All of this is happening asynchronously – in the background – using AJAX, and if you glance at the browser’s reload icon, you won’t notice a flicker: that also means, all of these interactions and calls between database and API's are happening without page reload, in the background, saving a lot of network traffic. I didn’t use any frameworks to build this, just jQuery library and with little help from PHP.
This application is an online DIY store, which you can browse and add products to a cart. I used Isotope js to filter the products. Once you’ve added a product to the cart and proceeded to the checkout, the application will establish whether you are logged in or not, and if not, it will ask you to login or register. If you are already registered or logged in, it will then take you through to the final checkout and payment process. For this multi-page application I combined both the techniques, some operations such as (add product to cart, update cart etc) are done with AJAX while register, login, checkout process, past order operations are with page reload. This would require a lot of user interactions, meaning lots of data transfers, network traffic and page reloads.
Verdict: Single-page applications can save on large amounts of data transfer between client and server, and can give web applications a desktop-like look & feel. Initially, this led to the problem that because there was just one page-load or “stage” in the process, hence dynamic content change was not picked up by search engines, so SEO (search engine optimisation) was ineffective. But Google has since announced that its crawler can now access information processed by Ajax calls. Either way, multi-page applications, on the other hand, are reliable, SEO-supportive, and comparatively easy to build. In the end it all depends on the nature and requirements of the business. In some cases, single-page applications will be suitable, and others, only multi-page will do.
Thank you John for your feedback. Glad to know that the post has been informative and answers some questions!
On August 28, 2020
Very informative! This answers many questions on how websites and web apps work