It's here – Sitecore's new cloud-native SaaS CMS, Experience Manager Cloud (XM Cloud for short), has [finally shipped](https://www.sitecore.com/company/news-events/press-releases/2022/07/sitecore-experience-manager-cloud-now-available). XM Cloud is the final piece of the puzzle to Sitecore's strategy of moving to a fully Composable DXP. While a move to the broader composable architecture brings many IT-focused benefits such as Sitecore-provided SaaS hosting and decoupled content delivery, the new XM Cloud CMS also offers important benefits for marketers in the form of a new content authoring experience.

XM Cloud is built as a SaaS product with a truly decoupled architecture for delivery of customer experiences (e.g. websites, native mobile apps, digital displays, etc.); however, the CMS itself also embraces the decoupled architecture with a new authoring experience application called Sitecore Pages.

## Introducing Sitecore Pages

![](assets/sitecore-pages-1a.jpg)

*Image source: <https://www.sitecore.com/products/xm-cloud>*

Sitecore Pages offers a no code / low code experience for marketers to compose web page layouts through the use of drag and drop UI components. Marketers are now afforded the ability to design their own bespoke page components in an elegant interface as a precursor to technologists getting involved with coding. This design-first approach to page layout and composition enables faster content authoring and page design cycles for marketing teams through the use of atomic UI components. Marketers can drag and drop atomic building block components such as text blocks, image blocks, etc to design and layout their own reusable page components.

The new Sitecore Pages authoring experience supplements the existing authoring experience of the CMS because its provided by Sitecore as a separate SaaS application that communicates with XM Cloud through headless content management APIs. Not only does this show that Sitecore has built its product following a truly decoupled architecture, but it also now provides flexibility for how content authors conduct their work. Authors can design custom components in the new Sitecore Pages app and synchronize page layouts with XM Cloud, or authors can continue to leverage the existing Experience Editor interface directly on XM Cloud to design page layouts through traditional UI components.

The introduction of Sitecore Pages to the XM Cloud product positions Sitecore as an innovator by offering efficiency and power to marketers through the no code / low code interface. Low code technology has been a [growing trend over the last several years](https://www.gartner.com/en/newsroom/press-releases/2021-02-15-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-23-percent-in-2021), and its great to see Sitecore find a nice use case that fits within their technology product model.

## Experience orchestration from any content source

![](assets/sitecore-pages-2.jpg)

*Image source: SUGCON Europe 2022*

Sitecore Pages takes a further step to truly empower marketers to own the experience orchestration layer, that is, the glue the combines all of the capabilities of the DXP, through a source-agnostic stance to content. While content being delivered through experiences provided by XM Cloud and Sitecore Pages can live in Sitecore, Sitecore Pages also offers data source connectors to other content systems such as several common pureplay headless CMS's. This truly positions Sitecore as an enabler by putting a focus on the experience orchestration capability of the DXP, regardless of where the content comes from. Customers that have multiple CMS platforms with separate content repositories can leverage the authoring experience of Sitecore Pages to combine and compose page templates using out of the box data connectors or though custom built connectors to their source systems.

This [product release](https://www.sitecore.com/products/xm-cloud) is brand new in the Sitecore ecosystem, so watch this space closely as updates are very likely over the coming months.

Sitecore Pages innovates with a new authoring experience.

Sitecore's new XM Cloud offers an improved authoring experience with Sitecore Pages

XM Cloud is finally here. I bet you are wondering what it is and how it compares to the previous Sitecore CMS products (XM/XP PaaS or on-premises) you've been working with for years. Let's unpack what XM Cloud is so an experienced Sitecore developer can understand how their development methodology may change.

## XM Cloud is based on XM

As the name suggests, XM Cloud is based on the traditional XM product you may know. XM is a simpler version of XP with a focus on content management and limited personalization features. While XP represents the full platform that includes content management, personalization, content testing, etc, XM focuses on content management and page layouts for the most part.

XM Cloud is the new breed of CMS from Sitecore based on XM, not XP. "Why not base it on XP?" you may ask. Sitecore has been on a journey to a Composable DXP for a few years now. The philosophy of the composable model is that each capability area is decoupled from others and independent. While XP represented a larger feature-baked platform, XM is the content management capability only. So it’s a natural choice for the new content capability of the Composable DXP to start here.

## XM Cloud is headless

![](assets/xmc-1.svg)

The largest impact for developers with XM Cloud is the adoption of a purely headless CMS. That mean no more Sitecore MVC (technically you can build a .NET MVC site with it, but it needs to use headless APIs, not Sitecore DLLs for context). The headless model decouples the CMS application from the experience you intend to build with it, whether it’s a content marketing website, a web portal, mobile app, etc.

This means:

* No more Sitecore MVC
* Developing a website will require you to implement [headless services](https://doc.sitecore.com/xp/en/developers/hd/200/sitecore-headless-development/sitecore-headless-services.html) ([JavaScript SDK](https://doc.sitecore.com/xp/en/developers/hd/200/sitecore-headless-development/sitecore-javascript-rendering-sdks--jss-.html) or [.NET Core SDK](https://doc.sitecore.com/xp/en/developers/hd/200/sitecore-headless-development/sitecore-asp-net-rendering-sdk.html)) or via direct API calls to Layout Service, [Experience Edge](https://doc.sitecore.com/xp/en/developers/hd/200/sitecore-headless-development/sitecore-experience-edge-for-xm.html) etc.
* Sitecore will no longer host your website, just your CMS
* No more Content Search API and directly using the Solr index

## XM Cloud is SaaS

![](assets/xmc-2.svg)

Sitecore's CMS is now SaaS! Because your website implementation is now headless and not hosted on the same application as the CMS (it's not possible), Sitecore has made XM Cloud a SaaS product. You are responsible for your own web server to host your website -- in Sitecore terms its called a Rendering Host. Sitecore is responsible for spinning up a "limited" CM instance in their SaaS infrastructure.

How do you make that happen...?

## XM Cloud provides new developer tooling

![](assets/xmc-5.svg)

Sitecore now provides a cloud portal and a [CLI to provision](https://www.youtube.com/watch?v=a23g2TRUvOI) and manage XM Cloud instances

Additionally, since we're now in the world of SaaS, many other things need to be provided as services that Sitecore now owns:

* Identity management via Sitecore Unified Identity
* Deployment tooling for the CMS instance

Wait, what? Deployment tooling for the CMS instance? I thought this was headless?

Yes….

## XM Cloud allows CMS customizations too

![](assets/xmc-3.svg)

While I did mention above that XM Cloud forces your end experience to be headless, Sitecore still allows you to deploy code such as a traditional .NET project to the XM Cloud CM instance they are hosting as SaaS.

This means you can (still) do the following:

* Serialize developer content items via source control and deploy to CM
* Deploy and execute content migration scripts
* Deploy and respond to pipelines and events in the CMS
* Customize the CMS with custom editors, command/buttons, etc.

## XM Cloud offers a new authoring experience with Sitecore Pages

![](assets/xmc-4.svg)

As a great new addition to the product, XM Cloud will also offer a new authoring experience in the form of a separate SaaS application called Sitecore Pages. This will allow a new experience with authoring content separate from the Content Editor or Experience Editor directly on the XM Cloud CM instance.

Sitecore Pages is hosted by Sitecore as SaaS and communicates to the XM Cloud CM instance headlessly. More to come on this topic when we learn more!

How does XM Cloud compare to traditional XM/XP?

Understanding XM Cloud for Experienced Sitecore Developers

Sitecore released Experience Edge capabilities a while back for their Content Hub (SaaS) product and their traditional XM (PaaS) CMS offering. What exactly is Experience Edge? If you think about the future vision of Sitecore's Composable DXP and the necessary architecture to support that, you can understand the role Experience Edge plays. Let's dig in and see how this fits, even in a traditional architecture.

## Sitecore Experience Edge: Decoupling the API at the Edge

For those with prior experience with Sitecore, the simplest definition I can give of Experience Edge is a modern replacement/substitute for Content Delivery (CD) servers. It's much more than that, but that's an easy mental model to wrap your head around its role. 

In a traditional XP/XM/XC platform-based scaled architecture, you will have at minimum a Content Management (CM) server hosting the back-end CMS and preview features, and one or more Content Delivery (CD) servers, rendering your site(s) to end users. The CM facilitates publishing (that is, moving content from the master database to the web database), and the CD reads the web database content and renders pages (traditionally via server-side .NET).

**Experience Edge for XM removes the need to host a set of CD servers on PaaS infrastructure and becomes a proxy layer between the CMS and the front-end customer experience**. This does come with the requirement that you are using the headless APIs provided by Experience Edge, as opposed to building a traditional MVC solution on XM that uses C# APIs. However, thats the future vision of the composable DXP with XM Cloud (the future CMS) being fully headless and decoupled. The primary point here is that you are able to start to take advantage of a [decoupled architecture](/post/simple-headless-cms-definition-in-one-sentence) using headless services for your front-end experience, even on a traditional XM PaaS deployment. While doing so you can shed the burden of hosting and scaling CD servers and allow Experience Edge to replace them as an API proxy.

#### That's it? No…

There's so much more. Experience Edge is provided as SaaS from Sitecore. Think of it as a Sitecore-provided CDN for your headless APIs that sits on top of your PaaS-hosted XM instance. You manage your XM instance in a PaaS hosting environment, and it publishes content to Sitecore's hosted Experience Edge which serves your GraphQL APIs for your front-end experience. From there you build and deploy whatever headless front-end experience you want, from a JavaScript-based site (React, Next.js, Angular, etc.) or a .NET Core site if you are C# .NET developer.

![Sitecore Experience Edge basic diagram](assets/sitecore-experience-edge.svg "Sitecore Experience Edge basic diagram")

### Good use cases for Experience Edge

There are a number of uses case of when it makes sense to leverage Experience Edge vs. hosting a set of CD servers in a PaaS environment:

* A **content marketing website** with largely static content - that is, non user-generated content (like blog comments). Even dynamic content from CMS publishing or time-based updates to content can be solved with static site generation (SSG) and incremental site regeneration (ISR).
* **Native mobile apps** that need to consume and surface CMS-managed content. These implementations are by definition headless, in that they use web APIs to deliver content from Sitecore to the app via its native code. Experience Edge will provide highly performant API endpoints for the native app to consume content, regardless of the state of the CMS (XM) behind the scenes.
* Bespoke **single page apps** (SPAs). This is related to content marketing sites, but in the case of a JavaScript-driven SPA, this is a great use case for using a performant headless API. We [implemented a 3D virtual experience SPA](https://www.rightpoint.com/work/genpact-oasis) that relied on a browser-based panoramic tool which was fed with CMS-managed content. This required the use of headless APIs to drive the experience.
* **Chatbots** and **virtual assistants** - pretty much anything that needs to consume raw content as-is. The UX of a chatbot is provided by the chatbot technology, but it requires input from customers (questions) and output content from.... somewhere. Why not store that content in a CMS? This is a perfect use case of a API to deliver the content.
* **Authenticated portals** - this one might sound peculiar, but its actually quite a good use case. If you need to build a portal with a logged in state, chances are a lot of the data to hydrate in the portal comes from another system of truth, e.g. an ERP or some other back-office system. It's not likely you are driving all of the content/data from a CMS, but a CMS can help augment content in the portal, such as page definitions/URLs, basic header titles, imagery, SEO content, etc. Chances are you can architect the custom web experience implementation of the portal with the back-office system in mind, e.g. using a specific back-office technology as the first reponder to your web portal, and then integrate it with the Experience Edge GraphQL APIs where needed to fetch CMS-driven content.

What is Experience Edge? A new fundamental performant component in the journey to a composable DXP.

Sitecore's new architecture - Experience Edge

This is the fourth post in a series on Sitecore XM Cloud and the pivot to headless decoupled delivery:

1. [Sitecore XM Cloud's headless content delivery is good for Sitecore](/post/sitecores-headless-content-delivery-is-good-for-sitecore)
2. [Sitecore XM Cloud's headless content delivery is good for developers](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-developers)
3. [Sitecore XM Cloud's headless content delivery is good for Sitecore partners](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-sitecore-partners)
4. Sitecore XM Cloud's headless content delivery is good for customers

So far in this series we've talked about why a move to headless content delivery is good for [Sitecore as the product innovator](/post/sitecores-headless-content-delivery-is-good-for-sitecore), [developers that implement customer experiences](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-developers), and [Sitecore partners](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-sitecore-partners). In this final post we will round things out for customers, the reason we design and build solutions in the first place.

## Headless Delivery is Good for Sitecore customers

At the end of the day, the product exists for customers. So what benefits can they get out of this headless-only model? Well, all of the prior reasons mentioned - customers benefit from all of the benefits above because everything else is in service of these customers:

- Customers have **more technology options** of how they implement (or have their partner implement) an experience: this opens up the door to more partner options and/or more in-house engineering options. No more do they need .NET based internal teams to build solution. If there's an existing team that's more front-end oriented, Sitecore offers rich SDKs for React, Angular, Vue, and Next.js.
- Customers have **more hosting options**: if they want to host the site themselves (or manage it on a cloud themselves) or have very unique hosting requirements, as long as the technology can consume the APIs, they are good. There's no longer a need to focus on Microsoft-based hosting since the CMS is SaaS and the front-end CX can run on any web technology.
- Customers can achieve **global reach and performance** more easily: since the website is decoupled from the CMS and it has all of the flexibility mentioned above for hosting options, customers can focus their energy on building performant front-facing experiences while taking advantage of new modern techniques such as Static Site Generation (SSG) and hosting on the edge.
- Customers can expect **more security**: now the CMS is decoupled from the website and Sitecore can focus its efforts on ensuring the security of the CMS is sound. If a customer decides to build their site using Static Site Generation (SSG) they can attain more security since there is no back-end server responding to page requests. 
- Customers can receive **CMS feature updates more easily**: now that the underlying CMS is hosted by Sitecore as SaaS, this enables Sitecore to better control releases of features as updates.

As you can see, customers benefit from all of the architectural changes with the release of XM Cloud. The next step to consider on the journey to XM Cloud is a migration path. Stay tuned for my next series on that topic!

Learn why a shift to a headless-only content delivery model with XM Cloud is good for Sitecore customers.

Sitecore XM Cloud's headless content delivery is good for customers

This is the third post in a series on Sitecore XM Cloud and the pivot to headless decoupled delivery:

1. [Sitecore XM Cloud's headless content delivery is good for Sitecore](/post/sitecores-headless-content-delivery-is-good-for-sitecore)
2. [Sitecore XM Cloud's headless content delivery is good for developers](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-developers)
3. Sitecore XM Cloud's headless content delivery is good for Sitecore partners
4. [Sitecore XM Cloud's headless content delivery is good for customers](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-customers)

The prior [post in this series talked about why a move to headless content delivery is good for developers](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-developers) with a more open development model. In this post we will cover why headless is good for existing (and emerging) Sitecore partners. As with development professionals, now is a great time to become a Sitecore partner with the openness of the platform. Let's dig in.

## Headless Delivery is Good for Sitecore partners

Building off what was mentioned in the [prior post](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-developers), Sitecore partners are at the intersection of other parties involved - Sitecore, developers, and customers. Partners' developers now have more freedom to choose what language to develop experience implementations with, which can enable front-end teams to develop Sitecore solutions (vs. the traditional "back-end" .NET teams that focused on Sitecore solutions in the prior monolithic products).

Partners also now have a better opportunity to work with customers to support the hosting of websites since the site's _rendering server_ is decoupled from the CMS (hosted as SaaS by Sitecore). While there always was an option for hosting Sitecore solutions in an Azure PaaS model, that typically  meant hosting both the CMS server and one or more front-facing website CD servers to deliver customer experiences. **Now that Sitecore hosts the CMS as SaaS, this will let partners focus their energy around front-facing website hosting for end users**. Couple this with the technology freedom that comes with headless APIs/SDKs, and partners are now more than ever enabled to come up with many novel hosting solutions within the world of Sitecore solutions.

Here are some examples of hosting options partners can provide to customers while not worrying about the back-end CMS hosting:
- **Vercel**, **Netlify**, or **Azure Static Web Apps** for a static site built with Next.js via the React Next.js headless SDK
- **Azure PaaS** (or IaaS if you really want) for a site built with the .NET Core SDK


Learn why a shift to a headless-only content delivery model with XM Cloud is good for existing (and new) Sitecore partners.

Sitecore XM Cloud's headless content delivery is good for Sitecore partners

This is the second post in a series on Sitecore XM Cloud and the pivot to headless decoupled delivery:

1. [Sitecore XM Cloud's headless content delivery is good for Sitecore](/post/sitecores-headless-content-delivery-is-good-for-sitecore)
2. Sitecore XM Cloud's headless content delivery is good for developers
3. [Sitecore XM Cloud's headless content delivery is good for Sitecore partners](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-sitecore-partners)
4. [Sitecore XM Cloud's headless content delivery is good for customers](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-customers)

The prior [post in this series talked about why a move to headless content delivery is good for Sitecore](/post/sitecores-headless-content-delivery-is-good-for-sitecore) as the product innovator. In this post we will cover why headless is good for developers. If you are a legacy platform (XP/XM) developer with years of experience doing Sitecore MVC, you have no need to worry with headless development. There is a way to transition while keeping your current skills.

## Headless Delivery is Good for developers

As you can guess, the pivot to a SaaS headless CMS affords many benefits for developers. One benefit is that it opens up development options for Sitecore developers. Instead of needing to be a C# .NET MVC developer, you can now pivot towards more modern front-end development languages (React, Angular, Vue) and frameworks (Next.js). If you are an existing .NET developer and worried about learning front-end, you can still use the .NET Core SDK as well to leverage your existing skills. Wait, what? Really? Yes.

**Headless development is not front-end development**. While headless systems often cater to front-end developers, that's more a function of the growing discipline of front-end as a full-stack development model, handling both the UI and back-end via server-side JavaScript with Node.js. Just because a product provides a headless API layer doesn't mean you need to use these modern front-end frameworks like React and Next.js to do your development.

While this is all good for existing Sitecore developers, the primary and more impactful benefit here has nothing to do with (existing) Sitecore developers. **Now more than ever, any web developer can be a Sitecore developer**. This greatly opens up the Sitecore development ecosystem to many more web professionals (or amateurs) with the new APIs and SDKs. The removal of the platform-native C# .NET APIs unleashes this. Since all of the APIs now communicate over HTTP between the CMS and the decoupled front-end customer experience, any web-enabled language can consume content from Sitecore to power an experience. Developers can use any of the following technologies to get started with Sitecore:

- [.NET Core Rendering SDK](https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/sitecore-asp-net-rendering-sdk.html) - a great way for existing Sitecore MVC developers to transition
- [JavaScript Rendering SDK](https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/sitecore-javascript-rendering-sdks--jss-.html) - great for front-end developers using React, Vue, Angular, and Next.js
- Advanced lower-level APIs that any web-enabled language can consume: the [Layout Service (REST)](https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/layout-service.html) and [GraphQL](https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/sitecore-graphql-api.html)

As you can see, the implementations options are infinitely more open compare dto the prior versions of the product. I see this as a huge opportunity for more developers to join the Sitecore community. One small caveat is that if you are attempting to make edits to the CMS itself (i.e. the back-end SaaS authoring application hosted as SaaS from Sitecore), you will still need to do that development in .NET since it is built in .NET Core. This includes things such as serialized developer content items, C# event handlers, customizaitons to the CMS via C# code, etc.


Learn why a shift to a headless-only content delivery model with XM Cloud is good for developers.

Sitecore XM Cloud's headless content delivery is good for developers

This is the first post in a series on Sitecore XM Cloud and the pivot to headless decoupled delivery:

1. Sitecore XM Cloud's headless content delivery is good for Sitecore
2. [Sitecore XM Cloud's headless content delivery is good for developers](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-developers)
3. [Sitecore XM Cloud's headless content delivery is good for Sitecore partners](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-sitecore-partners)
4. [Sitecore XM Cloud's headless content delivery is good for customers](/post/sitecore-xm-clouds-headless-content-delivery-is-good-for-customers)

Sitecore is currently going through a major transformation of its product suite into a composable DXP. One major component of the DXP, the CMS at the core, is also going through a massive re-architecture. The new CMS, XM Cloud, will offer a completely headless delivery model on top of a SaaS product. Let's learn why this shift to a headless-only model is good for Sitecore sthe product innovator.

## Headless Delivery is Good for Sitecore

As the product innovator, Sitecore greatly benefits from a headless-only delivery model for the content coming out of XM Cloud. Going headless greatly reduces the surface area Sitecore needs to consider "owning." Sitecore can now focus purely on the CMS and developer-friendly APIs/SDKs to build experience with. Yes, there's now more burden of building and supporting these SDKs (especially if they add more for languages over time), but it also allows Sitecore to shed some burden.

Sitecore is no longer in the business of hosting websites. Let that sink in. Sitecore's existing XP PaaS offering includes the option to host with Sitecore Managed Cloud (SMC). SMC provides hosting for the CM instance ("CMS") and multiple CD instances ("website delivery servers"). That means they need to worry about the performance and uptime of the authoring environment and the front-end website servers as well. This also creates a gray area of responsibility - if your website goes down but the app service on Azure is running fine, is Sitecore responsible for the resolution?

With XM Cloud, Sitecore will now focus on hosting the CMS itself as a SaaS offering. They can make the leap to SaaS now because the boundary between the CMS and the "front-end website" is completely decoupled (if you need a refresher on the decoupled model, check other [my other post on the topic](/post/simple-headless-cms-definition-in-one-sentence)). The hosting of the "front-end website" is now in the hands of the customer or a partner - freeing up Sitecore to focus on DXP product innovation.

Learn why a shift to a headless-only content delivery model with XM Cloud is good for Sitecore.

Sitecore XM Cloud's headless content delivery is good for Sitecore

There are many articles out there attempting to define and describe headless CMS. When I was drawing a diagram (in PowerPoint... because that's where I draw diagrams these days...) for a client to show a headless architecture vs. traditional/coupled architecture, I realized the primary differentiator is one thing. All of the latest and greatest "new" cloud-native headless CMSes will say that to be a real headless CMS you need all of these other things (cloud-native, headless first, developer-driven, blah blah blah), but architecturally, it's really just about data flow.

**My one-liner:**

> A headless CMS is one in which the *head* - an experience implementation (e.g. could be a website or mobile app codebase) - reaches **backwards** and fetches content **from** the CMS, as opposed to the CMS pushing content **into** the experience.

Please allow my PowerPoint diagrams to illustrate this:

![](assets/traditional-cms.svg)

As you can see in the diagram above, a traditional CMS will run the website in the same application as the CMS itself. It's a single "package" when it comes to hosting. A request to the website comes to the CMS part of the application and it "pushes out" a server-side response with the website code hydrated with CMS-managed content.

![](assets/headless-cms.svg)

And a headless/decoupled CMS will run the website itself in the separate application from the CMS. A request to the website hits the custom application, and it then decides if it needs to fetch content -- if so, it dispatches API calls to the CMS. In the case of static site generation (SSG), it ends at the custom app since the CMS content is hydrated into the custom app at build not, not runtime.

Simple Headless CMS Definition in One Sentence

I've been working with Sitecore for over a decade, so its no surprise that I have a bias towards Sitecore. As I've been reviewing headless CMS options on the market and comparing their authoring experiences and content modeling experiences with Sitecore, I've started to notice another compelling reason that Sitecore differentiates.

First, let's get one thing straight. Sitecore is a legacy "coupled" CMS with roots of a monolithic on-prem architecture. However, in recent years Sitecore has added new features and acquired technology that is allowing for more SaaS-based API-driven/headless composable architecture. Ok, I'll stop with the buzzwords.

One of the key features Sitecore rolled out a number of years ago is JSS: JavaScript Services. This was Sitecore's first differentiator in terms of a headless offering. Before that, Sitecore had Item Service and Entity Service which provided basic web APIs that could be used in headless use cases. But JSS offered something different.

JSS introduced a new paradigm to headless with the content authoring experience you expect from a coupled CMS with the ability to deliver content via a well-formed set of APIs and SDKs to get started. With JSS, you can build your front-end with JavaScript and take advantage of their framework-specific SDKs (Next.js, Vue, React, Angular) like you would expect with a headless CMS. However, you still can offer content authors the in-line editing experience with Experience Editor (and now Horizon editor) to compose page layouts with UI components/renderings. This, in my opinion, completely puts Sitecore on a different level than "native headless" vendors as it considers a great deal about the content authoring experience, something I am particularly fond of.

While I think headless vendors could come close to offering an experience like this, Sitecore being a hybrid headless vendor (that is, a vendor that provides both coupled and de-coupled CMS architecture) really affords them the ability to leverage both their coupled model and headless to provide the best of both worlds.

![Image of JSS components in Experience Editor](assets/experienceeditor4.png)

Image used from <https://developers.sitecore.com/trials/jss-connected-demo/exploring-sitecore/experience-editor>


Sitecore is a hybrid headless platform that differentiates from most other headless options.

One Reason why Sitecore Differentiates from other Headless CMS Platforms

As I explore headless CMS platforms, I plan to keep an eye on the content modeling experience. After all, the purpose of a CMS is to manage content. Having a rich and easy experience modeling the content is important for a number of reasons:

* Its the foundation of a content-heavy website, so getting the model done right and in a scalable way is important.
* The modeling experience should be easy and frictionless. If its hard to do it, your foundation crumbles nd you are more prone to errors or less likely to make adjustments to your model.
* Early on in a project, I find is very (very) useful to art modeling content ASAP. I prefer to put it in front of end users of the CMS (typically my client!). Why? Because the CMS is for them. They need to see and feel what it will be like to manage this content, and its relationships to other content.

So why do I think Sitecore is the gold standard for a content modeling experience? Well, maybe I'm being super biased and dramatic, but what I really mean is its my reference for for another other CMS. Sitecore offers a CMS-defined authoring experience via the CMS UI, as opposed to developer-first / code-first content modeling that requires code (C#, JSON, etc.). I find this useful for a few reasons:

* Easier to get up and running creating models in real-time with a end user / content author - you just need a running Sitecore instance (local or remote), you don't need a codebase yet
* Content authors can more easily see the model in the visual editor and understand it (vs. trying to undersand what that code if you are writing)

Stay tuned as we dig in under the hood to see what various headless CMS platforms offer in this area.

![Sitecore content model example](assets/sc-templates.jpg)

I'll be assessing headless CMS platforms with an eye towards the content modeling experience

Sitecore Content Modeling Experience is the Gold Standard

I added Netlify CMS to this blog. Pretty cool how it works. It's a 100% JavaScript CMS admin interface and works with existing sites that render content from Markdown files. The configuration allows you to model your markdown file format so the CMS interface knows how to parse and write Markdown. [Here's the documentation](https://www.netlifycms.org/docs/add-to-your-site/).

Mark as a Service