Choosing a Sitecore 10 Development Stack
With the introduction of version 10, Sitecore now offers numerous development architectures that cover a wide range of technology stacks:
- Web Forms
- Rendering Hosts
There are definitely pros and cons that come with choosing among these tech stacks. Each architecture features various strengths and weaknesses for both developers, users, and businesses. It is possible to mix-and-match, which can add complexity to a solution but also enable greater flexibility for developers and users. For example: building MVC-based sites that also use JSS to allow external applications to make the most of Sitecore's headless features.
Many factors go into deciding which stack to focus on: cost (both licensing and developer time), team experience (which affects long term maintainability), scaling needs, the desired user experience for content authors (especially in the Sitecore Experience Editor), and the possible future direction of the Sitecore platform.
Based on my experience with each of these technologies, here is a breakdown of the factors that should be considered when choosing a Sitecore tech stack.
Web Forms is still available in Sitecore 10, although it is based on legacy technology that Microsoft insists you no longer use. Do not start new Siteore projects on Web Forms. Please migrate legacy Web Forms solutions to newer technologies as soon as possible.
Sitecore MVC was introduced with version 6.5 and is well-understood and well-supported today. It's typically the default option for classic server-side component development.
Cost: Part of the core product - no additional licensing needed. Because Sitecore MVC has been around so long and because it's mostly similar to the traditional ASP.NET MVC patterns, it's fairly easy to onboard strong ASP.NET developers to Sitecore development. There is potentially a high cost of implementation if the dev team doesn't follow best practices from the get-go.
Developer Experience: Most ASP.NET MVC developers should be able to write Sitecore code and follow MVC patterns fairly easily. This should help lower the cost of overhead for businesses to maintain a solution since MVC is well supported and well understood across the .NET community.
Scaling: Pure server-side MVC-based Sitecore solutions will scale horizontally by deploying additional content delivery (CD) servers behind a load balancer to handle additional traffic. Sitecore's built-in caching layers/tools work well with MVC patterns, but can be tricky to implement on heavily-customized or personalized sites.
Usability: When implemented well, MVC-based solutions and components should work well in the Sitecore Experience Editor and Content Editor as an alternative option.
Future Outlook: Sitecore MVC should continue to be the default option for solution implementation for the foreseeable future. For businesses that want a reliable, well-understood option, MVC is the go-to.
Cost: JSS generally requires extra licensing costs for on-prem or cloud deployments. JSS costs may be integrated into consumption-based offerings from Sitecore.
Usability: When building components for a high-quality editing experience for content authors, JSS requires moderately deep knowledge of how Sitecore systems interact. FEDs who are averse to learning deep Sitecore concepts may need to work with a traditional backend developer to implement high-quality, components that are functional in the Experience Editor.
Future Outlook: Headless development is a core pillar of Sitecore's future, so it should be supported for several major versions going forward. The server-side pieces of JSS have recently been expanded to support rendering hosts (see below).
Sitecore Experience Accelerator
Sitecore Experience Accelerator (SXA) is a development and content accelerator maintained and supported by Sitecore. It's built using a combination of MVC and database-driven components (supporting concepts such as rendering variants that greatly simplify component variations).
Cost: SXA generally costs extra for on-prem or cloud deployments, but similar to JSS, can be integrated into consumption-based licensing options. As an accelerator, SXA can be very cost-effective if a solution is utilizing out of the box components with minimal customization. Extensivly customizing SXA components can potentially balloon implementation costs wit inexperienced.
Developer Experience:The learning curve for SXA can be challenging for traditional Sitecore MVC developers. SXA introduces several new component paradigms that go beyond classic MVC-based rendering and data structures. Themes and styling have been a pain point for past versions of SXA, but newer releases simplify these developer-designer workflows. Custom components must be built using SXA conventions. Once developers master SXA, however, future implementations can be greatly streamlined.
Scaling: SXA-based solutions are typically scaled the same as traditional Sitecore MVC: vertically or horizontally by adding additional CD servers as needed.
Usability: Content authors must use the Experience Editor to edit SXA-based website. This forces developers to focus on creating quality EE-ready components (which again, SXA facilities quite nicely), at the expense of a steeper learning curve as mentioned above.
Future Outlook: The immediate future of SXA is good: the latest releases have always introduced significant improvements over previous versions. The SXA team continues to maintain the product. The long-term future of SXA is a bit murkier due to the headless and SaaS focus of Sitecore in 2021. Because SXA is a core product with lots of resources behind it, however, expect it to be supported in the long run one way or another.
Officially introduced with Sitecore 10 in 2020, renderings hosts enable headless development for backend services and developers. Built on .NET Core, rendering hosts provide similar functionality as JSS: interacting with Sitecore rendering engines and content via APIs.
Cost: Renderings hosts are built into Sitecore 10, although future licensing costs with Sitecore's upcoming SaaS model are unknown. Traditional backend developers will have to learn a couple of new APIs and development paradigms to make use of rendering hosts. Overall implementation costs are currently unknown.
Developer Experience: Developing with rendering hosts is not unlike developing headless with JSS: a C# .NET Core application talks to Sitecore APIs to load content, process personalization rules, etc. Because the APIs supporting rendering hosts are new, developers can expect frequent updates and changes to the API over the next few years.
Scaling: Server-side deployments of rendering hosts can scale horizontally with CD environments. Similar to JSS, rendering hosts running in separate environments altogether can scale on their own terms. Sitecore CDs can scale vertically or horizontally to handle API load.
Usability: Components properly implemented via rendering hosts should be compatible with the Experience Editor similar to MVC- and JSS-based components. Again, this will require smart developers and a high-quality architecture to pull off. Content authors shouldn't notice any functional deficiencies compared to MVC components.
Future Outlook: Rendering hosts are at the center of Sitecore's new "developer experience" ("DevEx"). While JSS solves the client-server model of headless, rendering hosts are the server-side equivalent. Expect all Sitecore developers to become proficient with rendering hosts over the next couple of years.
Do you have questions, comments, or corrections for this post? Find me on Twitter: @BrandonMBruno