This process most commonly involves the page being refreshed, although some technologies, such as AJAX, do enable developers to alter some content without refreshing the entire page. Because of this, most websites act and behave distinctly like a website, rather than an application.
Most websites also have a tightly coupled back-end and presentation layer, meaning there is no real separation between the front and back end of a website, as both are part of a single monolithic application.
Over the last decade, native iOS and Android apps have become common place for almost all of us. These applications behave differently than actual websites, providing users with a very different, and often more satisfying, experience.
The application itself is the presentation layer, so it doesn’t need any of that from the back end server. This is much faster and allows the application to display the product details to the customer without refreshing a page. The technology gives developers freedom to build a seamless and fluid customer experience without the constraints of the traditional model.
Wouldn’t it be great if an app-like experience could be provided through a web browser so that the distinction between a native app and a website becomes blurred?
This is where Single Page Applications (SPAs) and Progressive Web Apps (PWAs) come in.
When a user first visits the website, the application, along with presentation resources (HTML, CSS, and some scripts) are loaded into the browser. From this point onwards, the user is on a single web page, and the application is loading the relevant content and altering the display as and when required.
Just like a native app, when a user clicks on a link, the application calls the back end server, which in turn sends the required data in a string, which does not generally include any of the presentation resources, as they’ve already been loaded when the user first visited the website.
Because the user is essentially only on a single web page, there isn’t really a concept of refreshing a page. Instead, the application alters the page to show different information when required.
SPAs are generally entirely de-coupled from the back end application and interfaces to the back end through a set of APIs. It will often sit on its own server and can deployed separately. In a way, it’s quite agnostic towards the back end application, as it’s simply sending and receiving data to and from it – treating it like a 3rd party system.
We’ve all been using SPAs for a while now, probably without even realizing it. Facebook, Gmail, Twitter, LinkedIn, and Instagram (among many others) all use SPAs in place of their websites.
If you visit any of those websites now, you’ll notice that they behave much more like a native app than a traditional website. Pages rarely, if ever, refresh when you interact with them, and are very fast. Clicking on links and buttons changes the content you’re looking at, but items like the header and footer almost never refresh once they’ve initially loaded.
The biggest and most obvious advantage of an SPA is how they can be used to improve customer experience by allowing designers and developers to provide an app-like experience and not be constrained by the traditional approach of reloading pages.
This does require a new way of designing and thinking, as the normal rules no longer apply, but the benefits to the user experience can be massive.
SPAs generally load content much faster than standard websites, as much of the presentation resources (HTML,CSS) are loaded only once. Interactions with the application only require a call to the back end server to retrieve small amounts of data, rather than fully formed HTML/CSS pages. The application can then rapidly display the changed data without having to reload the page.
Because an SPA is entirely de-coupled from the back end application, it can deployed separately, which can have a very big advantage. A small front-end change will not require the entire application to be deployed which can be quite a big task and sometimes requires downtime.
One of the biggest challenges of using SPAs is the impact it has on SEO. As they don’t always have the traditional structure of distinct pages, each with a distinct url, this can cause issues with search engines indexing the content. However, this can be countered with the use of techniques such as server-side rendering and ensuring that clicks do generate unique urls.
It’s also becoming less of an issue over time, as search engine bots are being changed to cope with SPAs. Google is one of the companies championing them, after all.
Some SPAs take a little time to load on the first visit because the application and presentation resources are loading on the first page view.
This is very noticeable with SPAs such as Gmail, where they have a big loading image when you first visit the website. This issue can be countered with the use of server-side rendering and efficient programming to ensure that the initial load of the application and resources is not too big.
A PWA is a little hard to define, as it’s not any specific technology, but more of a development methodology or set of principles that together make a website or application more or less PWA.
The term PWA was originally coined by Google, who created a checklist to define what makes a PWA. Among other things Google have defined that a PWA must be:
As you can see, some of the checklist items are a little vague or subjective. You can also see that some of them sound similar to an SPA. A traditional HTML/CSS website can be made into a PWA as can an SPA. An SPA isn’t automatically a PWA, but has some features that push it in that direction.
As with an SPA, one of the biggest advantages of a PWA is the improvement in the customer experience, giving it an app-like feel and bridging the gap between a traditional mobile website and a native iOS or Android app.
Features like the ability to save to your home screen or being able to cache pages through service workers can make the website look and feel a bit like a native app.
PWAs also tend to be very fast, as that’s one of the key principles in the checklist.
The Android operating system gives browsers access to the hardware of the mobile device. which allows things like push notifications and use of NFC scanning, which can really improve the CX.
The biggest disadvantage of PWAs is the lack of support from Apple. To get the best out of a PWA, it really needs to run on an Android device, as the Android operating system gives browsers access to a significant amount of features on the device, whereas Apple severely restricts this. This is slowly improving, but there’s still a long way to go.
Another disadvantage is the lack of a clear definition, which can be open to interpretation.
Although this technology is still not entirely mainstream for most e-commerce websites, it’s undoubtedly the future of website development.
While SPAs are a specific technology that can be used to build an e-commerce application, PWAs are generally websites that’ve been built following a methodology laid out by Google, which they feel provides the best customer experience.
Anyone developing an SPA should aim to meet the PWA checklist as much as possible in order to provide the best possible CX. These technologies give designers and developers more freedom in the user experience and journeys, allowing them to move away from the traditional page by page model.
Fewer and fewer e-commerce sites will be built using the traditional HTML/CSS model, and the gap between websites and native apps will get smaller and smaller, to a point where it’ll be hard to distinguish between them.
For more articles by Branwell Moffat also see https://www.the-future-of-commerce.com/contributor/branwell-moffat.