For years, Sitecore JSS has been the primary path for building headless Sitecore applications with React and Next.js. While powerful, JSS was created in a very different era of Next.js, long before the App Router, React Server Components, and edge-first rendering became the standard.

The Sitecore Content SDK represents a fundamental shift in approach. Rather than providing a framework on top of Next.js, it offers a set of lightweight, composable APIs that allow developers to build native Next.js applications without compromise.

This post explores why that distinction matters.

The Evolution of Next.js Left JSS Behind

Modern Next.js is no longer just a React framework with SSR:

• App Router is the default
• React Server Components are foundational
• Streaming and Suspense are core features
• Data fetching, caching, and revalidation are deeply integrated
• Edge and serverless deployments are first-class citizens

JSS, however, relies on:

• A centralized rendering pipeline
• Pages Router assumptions
• Client-heavy abstractions
• Runtime layout resolution
• Generated files and opinionated structure

As a result, teams often found themselves working around JSS rather than with Next.js.

A “Next.js-First” Mental Model

With JSS, developers had to learn:

• Sitecore-specific rendering concepts
• Custom lifecycle hooks
• Framework-generated conventions

With the Content SDK, developers use:

• app/ routing
• React Server Components
• Standard fetch semantics
• Suspense and streaming
• Next.js caching and revalidation

This makes Sitecore projects far more approachable for non-Sitecore developers and reduces onboarding friction.

Who does this really matter?

There are numerous technical and abstract benefits of upgrading to Content SDK from JSS, but this following simple example should make it crystal clear why it is so exciting.

Consider the following code snippet from a vanilla Next.js App.

export default async function Page(){

   const myData = await fetchData()

   return(

       <div>

           {myData.map((item,index)=>{

                <div key={index}>

                   <h2>{item.Heading}</h2>

                </div>

           })}

       </div>

    )

}

Seems fairly straightforward right? Using JSS this flow is not possible, but how do you think we would do the same thing using Content SDK? 

import sitecoreClient from "lib/sitecore-client";

export default async function Page(){

   //data structure simplified for example purposes

   const myData = await sitecoreClient.getPage('/')

   return(

       <div>

           {myData.map((item,index)=>{

                <div key={index}>

                   <h2>{item.Heading}</h2>

                </div>

           })}

       </div>

    )

}

Looks pretty much the same. This is the power of Content SDK. No longer are you siloed to a specific way of fetching data, but are able to learn the basics of Next.js and apply those to future Sitecore development in a cohesive eco-system.

Looking for more information or help migrating your existing Sitecore JSS site to Content SDK? Reach out to experts like my colleagues and I at XCentium.