The Sitecore Experience
Let’s take a look at the current options available for Sitecore implementations and how they’ve evolved over time. If you have been part of a Sitecore implementation that is more than a couple of years old, you can probably find your stack somewhere on this graphic.
There is overlap between some of the stages, really the graphic is looking to point out what was popular in each era of Sitecore.
Developer Experience (DevEx)
DevEx refers to the systems, technology, process, and culture that influence the effectiveness of software development.
I’m of the opinion that the DevEx of a stack has an out of proportion influence on the success or failure of a Sitecore implementation. It’s definitely not everything, there are other very important aspects. A quick graphic:
Having a solid DevEx foundation is key from the initial implementation to the long-term maintenance of an implementation.
Software savant Joel Spolsky came up with The Joel Test which is still used to this day as a reference of what good looks like. I also like this recent modernised version of it. Many of the questions are organisation / team process specific, but a significant number are DevEx.
Let’s look at each era and give it a rating.
2001–2010
Now I’m not old enough to have been doing Sitecore development in this period, but I’ve done my fair share of Sitecore upgrades to solutions utilizing XSLT and ASP.NET WebForms heavily.
There was not much custom client-side JavaScript happening at this time, mostly what was there was basic such as hiding and showing elements on the page, Ajax was driven mostly by using the WebForms functionality.
It was unheard of to have a unit test suite.
Since Sitecore has always been in the Enterprise space, source control was the norm (thank goodness), but deployments were almost always manual, perhaps if your team was particularly advanced they might have had a build server.
DevEx rating: 3/10.
2011–2014
ASP.NET MVC had been out for a couple years by 2011 and while there were a few projects still being kicked off utilizing WebForms, most were using ASP.NET MVC.
jQuery became part of the standard toolkit for a Sitecore developer.
Unit tests and Integration tests were the norm, but I found that the lack of maturity in the tooling and architecture during this time made many efforts a waste of time. I can think of a couple of examples where we would have to redo a large proportion of automated tests during development of a new major feature. This was likely a symptom of too tightly coupling rendering logic with back-end logic.
Dependency injection frameworks like Autofac and test helper frameworks like Moq were popular, but these didn’t stand the test of time with Autofac needing to be ripped out to be compatible with Sitecore 9+, and the amount of leaky spaghetti abstractions required to mock out Sitecore’s APIs meant that I saw on a few occasions an entire suite of thousands of unit tests get deleted as part of Sitecore upgrades as the cost of rewriting was not worth the benefit.
Many teams would have set up a Continuous Integration mechanism, consisting of something like TFS or TeamCity doing a build and running the tests. They likely would have had a basic deployment process consisting of a script that they run manually because there was no way in hell they trusted it enough to automate it. That coupled with the fact that Sitecore deployments of new features almost always required content updates and master DB publishes.
DevEx rating: 5/10.
2015–2017
Sitecore saw that many customers were facing similar challenges: they didn’t know how to architect a Sitecore solution in a way that mitigated many common problems in software development at the time resulting in flaky, buggy, slow, difficult to maintain implementations. So one of the OG Sitecore employees, Thomas Eldblom, was tasked with creating an open-source demo implementation — Habitat. He then used those architecture choices to create Helix — a standardized, official Sitecore development architecture and methodology.
This initiated a major shift in the space which had a net-positive outcome in DevEx. Sitecore finally had an architecture manual and reference implementation of what good looked like. On the downside, many teams naively cloned the Habitat repository which was designed for a specific demo use-case, and so the “Habitat is not a starter kit” meme was born.
One pain point in particular with Habitat is it came with a very opinionated suite of gulp scripts to build and deploy files to the local IIS instance. It was rather slow, cumbersome, and due to the changing Node JS landscape it was difficult to maintain.
Of course, when using a Microsoft .NET Framework based stack it’s best to stick to using msbuild and msdeploy, so in 2017 an msbuild magician called Richard Szalay released Helix Publishing Pipeline which not only negated the need for the gulp-based build and deploy scripts, it made packaging up the whole solution ready to deploy to production an absolute breeze. To this day I occasionally come across old Habitat based solutions, the gulp system almost always has been ripped out, but unfortunately not usually replaced with HPP, instead some other bespoke method such as using PowerShell to achieve the same thing.
Around mid 2016 a company called Cognifide had a Sitecore accelerator they called Zen Garden which was a decent set of pre-built Sitecore components and SEO functionality. Sitecore acquired this and made it a proprietary paid add-on that they called Sitecore Experience Accelerator (SXA). Part of this tooling was Sitecore Powershell Extensions (SPE) which thankfully was published open source and stayed that way.
I think the productisation and popularization of SXA was a good idea, but I think that keeping it closed-source has long hampered the product overall. Over the years I must have opened dozens and dozens of Sitecore support tickets for bugs in SXA. And I must have fixed scores more bugs and missing features by simply extending and customizing SXA myself. If the product was open source I would have been inclined to give back to Sitecore with these fixes done for them. I’d hate to think of the amount of support hours burned on hundreds of developers around the world opening tickets for the same issues. And the amount of productive time lost by those teams, being spent chasing down issues that are known to Sitecore but with the community having no visibility.
DevEx rating: 6/10
2018–2021
The worldwide market trend had well and truly shifted away from .NET to React.js.
An effort from Sitecore was put into creating Sitecore Javascript Services (JSS) as an offering to capture the market that wanted to use this stack and demonstrate that Sitecore could be a headless CMS.
The decision to open source JSS was excellent, I’d like to think it was from Sitecore having learned from their past choices. I have over the years created a few bug reports in the JSS repo and seen them get actioned by the JSS team. I frequently refer to the code during projects and it makes it so easy when a team member asks an implementation question and I can just direct link them to the JSS code for it.
Also around this time the “Cloud” was the big buzzword and we saw a few companies migrate their OnPrem solutions to IaaS (Azure / AWS virtual machines). This spearheaded an industry wide need for better products to reliably deploy code, and we saw changes like TFS being rebranded to Azure DevOps, Microsoft acquired GitHub, tools like Octopus Deploy became very popular.
Sitecore saw that they needed to provide first-class cloud support, and so partnered with Azure to get Sitecore running on the cost-efficient and scalable Azure PaaS.
There was a lot of change happening during this time, which means stability and maturity of dev tooling was in the process of being overhauled, and towards the end of this period I saw that many projects were launching with a decent DevOps setup.
SXA (for MVC) became much more mature, and overall did improve DevEx a lot by really standardizing and providing good tooling around what a well-built Sitecore component looks like. However, it always had a few key issues which really hold it back to this day:
- The client-side js (jQuery based) and stylesheets are difficult to customize and maintain
- The tooling around them (e.g. the bundler) uses a stack that hasn’t been updated since 2016, which is understandable but it means that you’ll be locked into the limitations of that era
- They are next to impossible to get a good core metrics performance score out of
- Item based rendering variants — aka the first low code way to build components — are difficult to maintain, test, and copy to other solutions. An interim idea that helped a little was introducing a templating framework called Scriban so that the code could at least be synced to source control, but this also has a lot of DevEx issues.
DevEx rating: 7/10
2022–2025
Sitecore Symposium 2022 saw the launch of XM Cloud which is basically under the hood Sitecore XM running on Kubernetes with a very slick Kafka implementation to orchestrate it all, with the new Sitecore portal as a user interface to manage it, and an option to use the Sitecore CLI if you need to do things the UI doesn’t yet do (such as Azure DevOps / Bitbucket integration — coming soon [TM]).
With teams no longer being responsible for hosting and maintaining the platform, coupled with teams shifting the rendering logic out of Sitecore and only using Sitecore as a headless CMS is a massive DevEx boost because it opens up SaaS products to take care of all the infrastructure for you. Just commit to your repo and everything else is taken care of.
Well, almost everything, you still need to know Sitecore pretty well to utilize it correctly and not make all the same mistakes of the past. You also might want to implement a unit test suite and a Storybook implementation which can pay dividends by making testing components in isolation a breeze.
Sitecore also released SXA for Headless (Next.js only at time of writing). I think they’ve learned a few lessons from SXA for MVC in not trying to be too prescriptive on exactly how you should be building and styling complex components. Even though SXA ships with full-blown Bootstrap 5 I was able to relatively quickly rip it out and implement my component library of choice.
I would however like to see them pare it down even further and leave us with the real basics, just the barest of bones in terms of UI styling. Remove Bootstrap (keep just Bootstrap Grid for basic layout functionality), remove Font Awesome, remove as many stylesheets as possible, don’t make any assumptions of how things like an Accordion should work, but do give us a way to make an Accordion fully Pages Editor compatible (which they have already done, thank you).
Overall it has been a monumental shift forward and I’m sure we will see some excellent Next.js + XM Cloud implementations over the next few years.
DevEx rating: 8/10
2026–2030
Sitecore has fully backed Next.js as the meta-framework of choice, and it’s a sound decision based on the market trend. However, it’s not a perfect fit for every single use case, and there are some frameworks and meta-frameworks that do some things better than others, which therefore improves DevEx for that use case. One such example is Astro which lets you use either React / Vue or Astro components on the same page at the same time, while still being very high performance. Anton Tishchenko, a community member, has ported the JSS SDK to Astro.
I have had the opportunity to work closely with both Next.js / React.js as well as Nuxt / Vue.js, the latter combination wasn’t a Sitecore project but a standalone user portal site. I absolutely love Nuxt/Vue, I think that Nuxt is superior to Next.js, but found that there is a big gap in terms of community support and contributions. As an example, there are so many very decent React component libraries to choose from to fit your requirements, compared to only a small handful of Vue.js component libraries. It is slowly gaining in popularity however, so once that gap closes it might become the technology of choice.
Another notable mention is to consider what Microsoft have been up to all these years while ASP.NET MVC gets sidelined? Well, they’ve been working on ASP.NET Blazor, and as of .NET 8 it really is ready for prime time. It’s raw performance and capability is stunning and could be an excellent choice if you need a seamless transition between ultra-fast server-side rendered pages and modern client-side functionality, and with .NET Maui for adding native App support relatively easily. I still think that it is lagging behind in terms of DevEx tooling and community support, but when it catches up it could be a game changer all over again.
