Supercharging Sitecore with SXA

Featured image

One of the most interesting discussions I had the last couple of weeks is when to use custom build solutions, maybe a boilerplate or Sitecore Experience Accelerator (in short SXA.  In my previous post I wrote about the feeling one can have when playing around with SXA, how I could use my own (React) components in SXA, but there is so much more under the hood.

In this post I will zoom in more into the world of SXA and try to convince you that SXA is the way to go.

Want to skip to the conclusion?

Choosing a Boilerplate over SXA


Over the years many companies discovered a way of introducing functionality and logic that were added to Sitecore: a framework or "boilerplate", to streamline development, enabling continuous delivery, governance etc etc. With this proven approach customers recognized a quicker time to market and therefore additional marketing campaigns were no budgetary issue because there was more money left to spend. One of the strangest things I have seen in the past is that SXA is seen as a fixed framework with its own set of components and fixed way of working and that's why some organisations will not even think of using SXA.

Choosing SXA over other frameworks

An different question is whether one should abandon the boilerplate and focusing primarily on Sitecore Experience Accelerator. SXA out of the box will provide a lot of extra's like:

Going this way will actually boost your time to market and provide you with a site in no time. Many things are available from the front-end where in the past one would need developers to make changes or add functionality. This problem has been removed because SXA has a mandatory dependency to Sitecore PowerShell Extensions. Creating a site has never been easier. A set of PowerShell scripts are executed under the hood doing all kinds of things to scaffold the entire structure for you. When done you can start setting up your pages right away without any pain.

SXA the Hybrid way


My view is simple: I think that one should not abandon any framework, boilerplate in any way when it comes to logic and functionality that is not provided by SXA. Best of both worlds often might give the best results. As stated earlier a boilerplate often also dictates the flow of development (Helix) and in the end will speed up the process taking in account all other processes.

Using only SXA is in my opinion not the right way because when it comes to Atomic Design you do now want a content editor to start scaffolding a web page using atoms and molecules, even if it is a button. Rather use a rendering variant to solve presentation issues.

A small comparison:

SXA Boilerplate
Redactional SXA component toolbox Default
Content Helix Helix (if implemented)
Design If only SXA then it could get rigid Full freedom, clean HTML
Marketing Short TTM, no dev required Relative short TTM, dev required
Governance/Admin/Update All new logic is provided when a new update arrives Maintain by yourself
Commerce OOTB

The mix of your own boilerplate with SXA will supercharge your process and combine speed and ease. SXA has a lot of great features most boilerplates don't have which makes to combination of the two so special.

SXA is here to stay and I am sure we'll see more and more in the near future (think Commerce 9). I am very curious of other peoples views on the subject so I hope this post is a nice start for a discussion :-)