Thoughts on the Sitecore Experience Accelerator (SXA)

The views expressed in this post are entirely my own based on my own experiences.

What is it?

Previously a module and now built in to Sitecore 9, SXA is a set of layouts and components to allow drag-drop creation of a Sitecore website without developer interaction.

The underlying grid system is defined by Sitecore. You can choose from Bootstrap, Foundation or Grid960, and also create your own grid system but what you are somewhat restricted to allow SXA to work. Through Sitecore you can design your layout adding columns and placeholders ready to drop components.

SXA comes with a library of common components that can be used out of the box and dropped onto the page.

When SXA could be a good fit

Sitecore claim SXA will get your websites up and running faster and allows backend, front-end and content to all happen simultaneously. This is somewhat deceiving as in real world scenarios I only see a small number of situations where this may be true.

One valid use case would be that a client needs to create many microsites inside their Sitecore instance without developer help, and only with simple CSS styling that can often be done by a design agency without front-end developers. Perhaps an advertising agency that needs to create many campaign microsites that need different layouts and components. Here SXA is a good fit and with a few clicks a new website could be up and running, but prior to this there would likely need to be a full development phase from a development company whereby Sitecore has been configured properly and any custom components built and deployed. After this point the advertising agency could go forward and create microsites on their own.

“SXA may be a good fit for organizations that use a lot of highly structured sites that make use of shared content. Examples include chapter sites for associations, franchisee sites, affiliate storefronts and conference/event sites.” 1

Other reasons to use SXA may be for small implementations where requirements are already met by existing SXA components or where the development team doesn’t have the time, experience or resources to take on a larger development; perhaps an organization with a single internal developer. That said in both these cases the question really should be is Sitecore the right product? You could still leverage the marketing features of Sitecore if that was beneficial, but the end result will be a cookie-cutter website which you could get from any number of other CMS systems some of which are open-source and free.

The problems with SXA

Something like SXA is trying to be a one-size fits all website generation tool and with anything of that nature there will be compromises to the quality of the finished product. The HTML generated is controlled by the SXA Grid system taking away all control from the front-end developers.

“SXA may not be a good fit for organizations that desire highly customized & intricate presentations and have highly trained front end designers/developers. If your front end team is on the (b)leading edge with React, Redux, Axios, etc. the structure of an accelerator will likely stifle their creativity and productivity.” 1

A similar issue will happen with the components in the component library. Due to the one-size fits all nature these components are bloated with libraries to make them backwards compatible, and you have no choice but to use them as is. Adding a single component to page can result in a plethora of references to JavaScript libraries bloating the page and load times. These may be minified by Sitecore, but they may not be needed at all and as a developer you are losing control.

SXA promotes a somewhat backwards website creation process. Traditionally you start with designs that are approved by a client which then go to front-end developers to create the mark-up and any other front-end functionality required for the website. The choice of any grid or templating system as well as libraries used should be driven by the design and specific requirements of the website.

With SXA with page layouts are created inside of the Sitecore user interface and with a click of a button all of the assets (CSS/JS/HTML) are output in a ZIP file ready for the front-end developers to style.

“The idea that Sitecore Developers can create a bunch of components throw it over the wall and a front end team can get everything to look perfect is naïve.” 2

The idea is that front-end developers would then add their own styles to the mark-up which is then reimported back into the Sitecore media library ready for the website to use. This is an approach that any self-respecting front-end developer would find insulting, and it based on an outdated understanding of what front-end development is. It is extremely restrictive on front-end development dictating the process and toolset that a developer can use, which is not something a CMS should be doing.

Another major concern to this approach is that all of the front-end assets are stored in the CMS. They are not properly version controlled and could be edited inside Sitecore. Of course, the exported assets could be version controlled, but they are not the exact assets used by the website. When it comes to deployments there would be a lot of additional work required. For automation you’d need to serialize the items to allow them to be deployed to other environments, and those items would be source controlled. At this point you could have the assets in two different source control repositories, one outside of Sitecore and one serialized as part of your Sitecore solution. In doing this there is a lot of overhead added for managing the assets and deployments that would not even be a consideration in a non-SXA build.

SXA documentation suggests that with SXA front-end and back-end development can happen in parallel implying that without SXA it cannot. This is not the case and a well-organized team with good communication can easily work on front-end and back-end tasks together, only here decisions on application architecture come from requirements and is not restricted by Sitecore. Everything rendered by the browser would be controlled by the development team ensuring high quality output that meets requirements.

Over the last 10 years the definition of front-end development has changed a lot, going from simple styling tasks to taking on a lot of the work that would have previously been done server side to provide a better user experience. The introduction of front-end presentation libraries such as Angular and React has accelerated this making it much easier for developers to create rich web applications using more traditional software design patterns that were previously only available to back-end developers. These tools and frameworks are evolving at an amazing pace, and even though SXA does use some of them, it will not be able to keep, resulting in a website using outdated versions of libraries or outdated technology altogether.

While it is possible to create a custom grid system in SXA and create custom components there is an overhead in creating those components, and you are still restricted on what you can do. In a scenario where a lot of custom work is required then using SXA will definitely add more time to development and not reduce time as it’s intended to do. In this scenario the only feature you’d really be getting from SXA is the drag and drop functionality.


There are a small number of use cases where SXA may be a good fit as mentioned previously, but for the majority of websites using SXA will actually increase development time and reduce the quality of the end result.

Sitecore have created SXA to fill a gap in their feature set, but for a system like Sitecore which I see as more of a framework to give developers full control of what they are building, SXA while filling a need, is a step backwards and doesn’t seem to fit with the way web driven development is heading which is a more front-end/API based approach.

Clients that choose to pay for Sitecore are buying a platform with powerful features that allow developers to build websites however they chose, and I think it’s unlikely that type of customer will be looking to have a cookie-cutter style website that won’t necessarily use the latest and greatest technologies.

For Sitecore development agencies 99% of the time SXA will not be saving time and it will be very restrictive and frustrating to developers, but as mentioned there is a small number of use cases such as microsites where it could be relevant. Even in those scenarios SXA would not necessarily be the best choice because a lot of the same functionality could be created using Branch Templates and traditional Experience Editor functionality for adding components into placeholders.



Posted on by Joe in Sitecore

2 Responses to Thoughts on the Sitecore Experience Accelerator (SXA)

  1. Jonas Päckos

    Thanks for this write-up. It confirms all my initial feelings reading through the documentation and watching various videos of configuring SXA and building pages.

    I’ve tried finding sources that describe how renderings and modules are edited in order to make SXA spit out modern and high quality HTML, but it seems you’re tied to use the generic div soup that Sitecore promotes as best practise.

  2. Joe

    Hi Jonas. Technically you could create a new grid system within the SXA structure giving yourself full control over the markup, then write all custom components using your own markup and libraries, but at that stage what benefit are you really getting from SXA. Most Sitecore agencies would be restricted by agency drop and wouldn’t want their assets in the media library, so at that stage the only SXA ‘feature’ you’re getting is drag and drop and the development effort is massively increased. I think a better approach is a set of reusable layouts and components utilizing dynamic placeholder and placeholder settings. That would still allow rapid spin up of new sites within a Sitecore instance without a deployment but the devs still have full control.

Add a Comment