First of all, you’re most likely a regular user of Single Page Applications (SPAs) already.
Single Page Applications are a great tool for making incredibly engaging and unique experiences for your users.
Some Single Page Application examples are like Gmail, Google Maps, AirBNB, Netflix, Pinterest, Paypal, and many more are using SPAs to build a fluid, scalable experience.
However, in the past SPAs have left marketers out in the dark when it comes to managing content. Luckily, it’s now possible to pair your SPA with the right CMS to give both developers and marketers the level of control they need.
What’s Single Page Application?
Single page application (SPA) is a single page (hence the name) where a lot of information stays the same and only a few pieces need to be updated at a time.
For example, when you browse through your email you’ll notice that not much changes during navigation - the sidebar and header remain untouched as you go through your inbox.
The SPA only sends what you need with each click, and your browser renders that information. This is different to a traditional page load where the server re-renders a full page with every click you make and sends it to your browser.
This piece by piece, client side method makes load time must faster for users and makes the amount of information a server has to send a lot less and a lot more cost efficient. A win-win.
What’s Single Page Application Architecture? How Does it Work?
The single page application is a web application or website that interacts with the user by dynamically rewriting the current page, rather than loading entire new pages from the server.
This approach voids interruption of the user experience between successive pages, making the application behave more like a desktop application.
On most websites there is a lot of repeating content.
Some of it stays the same no matter where the user goes (headers, footers, logos, navigation bar, etc), some of it is constant in just a certain section (filter bars, banners), and there are many repeating layouts and templates (blogs, self-service, the google mail setup mentioned above).
Single Page Applications take advantage of this repetition.
Let’s say your view of the website is a painting of a house and a tree. Traditional, multi-page websites paint the entire picture for you on the server and send it over to your browser.
SPAs give you the paint-by-numbers guides for the site, including the repeating guides you’ll likely be using, and then pipes the right paint (data and content) to fill out the template.
Either way you see the same tree, but the speed of SPA comes in when you request new content - like clicking on “next”, filtering results, opening a mail or - in this little metaphor - asking to see a different tree.
In a traditional website your request for a new tree would cause the server to repaint the entire picture and send it back.
With an Single Page Application, the server says “hey, I’ve got a new tree for you, but you’ve already got the house so just leave that the same”, then sends you updated instructions for a new tree and the paint to make it.
By transferring the painting work (page rendering) from the server to the client (you) the page can be dynamically rewritten, instead of going through an entire reload.
This makes things a whole lot faster.
Single Page Applications Advantages
There are many benefits to SPA solutions such as improved application performance and consistency, and reduced development time and infrastructure costs.
By separating the presentation from the content and data, development teams can work at different speeds while still being integrated for the overall solution. SPA is good for making responsive design for mobile, desktop and tablet.
[Advantage #1] Single Time File Load Each of HTML, CSS, JS
Single Page Application, after the initial page load, the server doesn’t send any more HTML to you - you download it all right at the beginning.
The server sends you a shell page and your browser renders the user interface (UI).
Then, as you click around, the SPA sends back requests for data and markup, the server shoots back the raw materials needed, and your browser takes it and renders an updated UI - interchanging pieces without ever needing to refresh the full page.
This quick interchangeability makes SPAs incredibly useful on pages that are highly navigated and use repeating templates.
[Advantage #2] No Extra Queries to Server
Because the server doesn’t need to spend time & energy doing the full drawing, SPAs lower the impact on your servers overall - meaning you can save money by using less servers for the same amount of traffic.
[Advantage #3] Fast and Responsive Front-end Built
Along with the quicker performance time explained above, SPAs also let developers build the front-end a lot faster.
This is due to the decoupled architecture of SPAs, or a separation of back-end services and front-end display.
Many business critical functionalities don’t change all that much on the back-end.
While how your customers log-in, register, purchase and track orders may change it’s “look” or presentation from time to time, the logic and data orchestration behind it is pretty constant - and you don’t want to risk messing it up.
Similarly, your raw content and data might stay the same but how you want to display it differs.
By decoupling that back-end logic & data from how it’s presented you turn it into a “service”, and developers can build many different front-end ways to show and use that service.
With a decoupled setup, developers can build, deploy, and experiment with the front-end completely independently of the underlying back-end technology.
They design how they want the user experience to look and feel, and then pull in the content, data, and functionality through those services.
This is done using APIs, which are a standard set of rules between applications on how they will structure, exchange, and reassemble data.
This API setup lets developers work quickly on the UI with no risk to business critical back-end technologies.
[Advantage #4] Enhanced User Experiences
As more and more functionalities are built as modular services (a microservice architecture) that can be updated independently, it becomes easier to experiment with how they are displayed and used.
SPAs frameworks are great for playing around with these services to create engaging, dynamic, and even animated user experiences.
Single Page Application with Angular vs React vs Ember vs Vue?
Angular and React (and many others such as Ember and Vue) are frameworks that developers use to create SPAs efficiently and eloquently.
Simply put, these frameworks are a collection of reusable components, that many developers have contributed to, that follow a defined set of building rules.
If you think of it like building a house, you could mix up the clay, dry the bricks, mine and mold the steel yourself - or you could use the bricks and pipes other people have already designed and focus your time on what makes your house unique.
As for the differences between them all, I’m no expert (but this guy seems to be), but a great thing about SPAs and the frameworks that support them is that, thanks to APIs, with the right integrations you can use whichever framework you prefer with your other API-enabled technologies.
Why Single Page Applications and CMSs Were Historically a Difficult Pairing
When using SPAs, developers may think of the experience as an “app” but the visitor is still going to think of it as a webpage, and where there is a webpage there is a marketing team itching to optimize it.
Because SPAs are apps that require development work to tinker with the display & delivery of the experience, marketers are having to go back to the digital stone age (aka the ‘90s) and ask for development help for every tweak - causing inevitable bottlenecks.
[Reason #1] Removed the editing tools Marketers are used to
The CMS editing features marketing teams rely on (live preview, drag-and-drop, WYSIWYG editing, etc) are usually tied to the delivery tier in the CMS.
With SPAs, the delivery is determined by the SPA and the content is simply stored in the CMS in standard way the APIs can read. Because the SPA is rendered on the front-end, the back-end CMS has no idea what it should look like and therefore can’t spin up a preview.
So CMS users end up getting stuck with a very dated approach - fill in a form, cross your fingers, push publish, and go see what it looks like live.
To return to our paint-by-numbers example, the CMS stores the raw content (the paint) and the SPA has the paint-by-numbers guide of how that content should look. The preview doesn’t have this guide, so can’t figure out what the content should look like.
This is a pure “headless” delivery of content (aka, it doesn’t have the CMS delivery tier as a “head”). It’s great for developing quickly, but a bit rough for marketers who want to change the website on their own without having to code.
Alongside that, Marketers are used to thinking of things in ‘pages’ but because an SPA is, well, a single page the page building and editing features marketers need aren’t available.
If they want a new “page” (a “route” in an SPA), or want the view to look differently, they have to ask a developer.
[Reason #2] Made it difficult to reuse content
This issue comes from two core reasons, one with antiquated CMSs and the other from SPA design.
First, there are certain CMSs where there simply isn’t a de-coupling of how your content looks and how it is stored.
Because the storage of content is not in a standard, presentation neutral format the SPA can’t use it in the API-based way is wants to.
This isn’t just a problem when using SPAs of course, this kind of CMS set up makes it impossible to reuse content across channels in general.
Because the content is tied to how it’s displayed (a page-based system), the FAQs you put on your website can’t just be tapped for someone to flip through on their smart watch - you’d have to store the same content in two different ways.
SPA’s need a content-based CMS to work properly, so that it can pull raw content and display it however it wants.
On the SPA-side, the difficulty comes from the fact that many websites are going to be a hybrid setup.
While you may want some parts as an SPA, you might want others set up in the traditional way (often better for SEO), and there needs to be a cohesive feel between these.
If your setup is two buckets of content, pieces for the traditional site and the SPA, that cohesion is going to break. You need content that works across everything.
[Reason #3] Difficult with Personalization/Relevance
SPAs grab content in a “service” way, so that it’s a little nugget of content without much context - not a big help in relevant delivery.
Are Marketers Doomed Forever in an SPA World?
Of course not! You simply need an CMS that has an architecture ready for SPA use.
One that is API-based, decouples content from presentation, can work with the SPA to provide a live preview & editing tools, supports a hybrid setup, and does personalization on the server side.
In below parts I’ll walk you through the way Bloomreach does just that.