DEV Community

Cover image for MPA != Website
James Luterek
James Luterek

Posted on • Edited on

MPA != Website

I need to rant for a moment about something I see happening repeatedly in the web development space. If you are here for professional educational content go find another article, otherwise buckle up because I’m about to go on an unhinged diatribe of terminology.

We need to unravel a mix-up that's been causing some serious head-scratching. I know this is ground-breaking so brace yourselves: an APPLICATION should never be confused with a WEBSITE. And since you read the title, you guessed it right, if an application is not a website, then a Multi-Page Application (MPA) is NOT, I repeat, NOT the same as a website. Can we please stop labeling websites, the things we’ve been building for decades as an MPA.

Applications are software that handles complex tasks. Originally, they were installed on a computer or server. Think spreadsheets, photo-editing, web browsers and more. By contrast, websites were a way to share information on the internet, consisting of multiple HTML pages accessed via URL. After the introduction of JavaScript, the idea came to build an application with JavaScript. Since this wasn’t a website, it lived on a single HTML page that simply loaded the application code. Hence Single Page Application.

So, WTF is an MPA then? The acronym originally referred to multiple Single Page Applications (SPAs) combined into a single final solution. Hence multi-page as there were multiple. This later became known as micro-frontends, probably because nobody used the term MPA correctly and all just used it to mean website.

I understand, this is how language evolves. A word is created, then the definition of that word is based not on the original purpose, but on how people use it. This is why definitions change over time and words that were once incorrect get added to the dictionary. So, at this point the ship has sailed, an MPA now means website, and website means anything served via a URL.

The problem is… now we need something to distinguish between a content driven website and a functionality rich application. They are completely different concepts that have different needs and considerations. Yes, transitional apps help merge the two allowing frameworks like svelte-kit to bounce back and forth between a server-rendered content page and a functional application, but being able to quickly make and identify the distinction helps clarify what needs to be build, and how we should build it.

Applications, at least what used to be called applications, require a rich UI with lots of interactivity. They need significant code to handle all the functionality. Initial load-time is less of a concern as people will spend hours to days interacting with the application. SEO is not a concern as people enter the application and then work on their own data.

By contrast, websites, or at least what we used to think of as websites, need to share mass amounts of information. They need good SEO considerations so the information can be indexed and quickly found by search engines. Page-load is extremely important as users may only visit one page and leave, and any page of information could be the entry point.

So, now that we as a collective community have completely messed things up by labeling MPAs as websites and completely obliterating the distinction between a website and application, how do we fix things?

I’m all for progress, but this just created confusion and added no value as we simply replaced one term with another less accurate acronym. As I said though, this ship has sailed, the genie is out of the bottle, the train has left the station, we can’t unring this bell. So, I ask the community, moving forward, how do we distinguish between the needs and functionality of Google Sheets and Wikipedia?


Subscribe - https://www.youtube.com/JamesLuterek

Top comments (2)

Collapse
 
larssalling profile image
Lars Salling

This is the first I've heard of this being a problem - I personally don't think it's that deep. The term single-page application, I think, was never created in order to distinguish between website and application, rather it was a label for the technology of being able to build sites (or applications) up through JavaScript alone. While I'm not aware how long the term MPA has been around, it seems as if it's just another technical term to describe the technology behind the product - being that it does not use client side routing - and can be used both for content websites and applications.
Wikipedia is a content website and Google Sheets is a web application.

Collapse
 
jluterek profile image
James Luterek

SPA was absolutely created to distinguish between an application and website. It was a direct decedent of Rich Internet Applications (RIA) which made the distinction of acting more inline with a desktop application as opposed to a website. RIA started with flash, but was quickly replaced with AJAX.

I know the history doesn't matter this much, we just need to build great software, but I do see confusion from new developers. It's unclear when they should use a SPA technology (i.e. React) as opposed to a server-rendered approach (i.e. PHP).

I'm sure with time someone will find a good way to describe these differences. That or meta-frameworks will continue to expand and blur the distinction to the point where it doesn't matter.