An Independent Sitecore Learning Resource

Menu

Choosing a Sitecore 10 Development Stack

Choosing a Sitecore 10 Development Stack

Author

Brandon Bruno

Published

October 20, 2020

Tags

With the introduction of version 10, Sitecore now offers numerous development architectures that cover a wide range of technology stacks:

  • Web Forms
  • MVC
  • JSS
  • SXA
  • 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

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.

MVC

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.

JavaScript Services

Sitecore JavaScript Services (JSS) was introduced with Sitecore 9 and has been fairly feature-complete and stable since then. It integrates nicely with frontend libraries such as React, Angular, and Vue.

  • Cost: JSS generally requires extra licensing costs for on-prem or cloud deployments. JSS costs may be integrated into consumption-based offerings from Sitecore.

  • Developer Experience: Because of its native support for popular FED frameworks, a frontend team is best suited to hit the ground running with JSS. There is typically little work for backend developers. JSS is also great for integrating native Sitecore features into existing JavaScript-based applications.

  • Scaling: Client-side JavaScript applications can scale on their own terms (CDN, etc.), and Sitecore can scale vertically or horizontally to handle whatever API load clients put on the platform.

  • 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.

Rendering Hosts

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: @SitecoreSpark