After Symposium 2017 in Las Vegas, I wrote a blog discussing Sitecore’s Experience Accelerator (SXA) and Headless concepts working together. For those not using Sitecore or unfamiliar with SXA, this product provides componentised Sitecore libraries, generating pre-defined HTML for website page elements, such as carousels, image containers and buttons. At the time of the conference, Sitecore had just announced its launch of Sitecore JSS to support a headless CMS approach. As more information has been released, the Sitecore community’s support for JSS is impressive, giving rise to a new category of developers across React, Vue and Angular. However, these two technologies (SXA and JSS), have also divided the direction of development approach, leading to options to suit any flavour of website.
SXA has the power and sophistication to deliver websites rapidly. For content authors, SXA has a predefined component library, complete with a drag-and-drop interface to create wireframes and automatically package up the HTML for front-end styling. The latest advances in SXA’s features have meant wider support for grids and friendly front-end tools like Vue, but the HTML is predefined by the Sitecore component, which will have its limitations for design components. While compromise on design isn’t necessarily advisable, understanding the HTML outputs before getting creative is the fundamental concession the project needs to make in order to leverage SXA and take full advantage of the libraries.
Sitecore JSS for a headless approach, on the other hand, can give you all the flexibility required as a front-end developer to translate every pixel created in the design process. Using the Sitecore JSS features, you can connect the front-end site with oData references. These are easily transportable and plug into Sitecore. Interestingly, Sitecore JSS does use SXA, but only the layout function; this means that going headless with Sitecore JSS won’t give you the drag-and-drop editing experience you receive from SXA and will be a key concession to make when embarking on a headless process.
While the creative liberty of headless will give customers a great UX, the practicality of maintaining a website with experience editor could sway many to SXA.
The answer is both. Why limit a website to one or the other, when you can have them running side-by-side or site-by-site. At Switch, we’ve been working closely with clients on developing use cases for each approach and matching them appropriately. Use cases could be campaign vs master site vs multi-tenant vs eCommerce store vs portal vs micro-site. Each requires the attention to the outcomes and development lifecycle of the site to determine whether a headless or SXA approach will work best.