Katie Lawson

Jul 24, 2018

Why SPAs and CMSs were historically a difficult pairing

Part 2 of a 4 part series.

In part 1 we discussed why Single Page Applications (SPAs) make the lives of developers a whole lot easier, and why they offer the potential to make incredibly unique and engaging experiences for your users. However, SPAs have kind of left marketers out in the dark when it comes to managing content.

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.

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 from part 1, 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.


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.

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. On top of that, a lot of CMSs do their personalization either page based (not helpful in an SPA), or on the client-side - and those javascript personalization rules don’t play very nicely on top of the SPA javascript. Too many cooks in the personalization kitchen if you will.

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 part 3 I’ll walk you through the way BloomReach does just that.

How to Use Single Page Applications with a CMS

Prefer PDF? Read the full SPA story here. 

download the guide
How to Use Single Page Applications with a CMS