When I first started working on Sitecore XM Cloud and headless Sitecore projects, it was always Next.js. It felt like the default choice – and honestly, for a good reason. But over the past year, I’ve have seen and worked on projects that have their JSS apps in React – the standalone version, without Next.js.
This got me curious. Why React? What’s missing when we move away from Next.js? And most importantly – what should we choose when starting a new Sitecore project?
This post breaks down everything I uncovered while switching between the React and Next.js JSS SDKs – from core concepts to Sitecore-specific implementation differences. If you’re gearing up for a new Sitecore XM Cloud build or architecting a headless Sitecore app, this will help you make informed technical decisions.
React vs Next.js – A Quick Overview
Before we compare the Sitecore JSS SDKs, it helps to understand the difference between React and Next.js, since these form the foundation for the SDKs.
React
React is a JavaScript library for building interactive user interfaces, primarily using a component-based approach.
It handles the view layer only and leaves routing, SSR, and other features up to you.
- Created by Facebook
- Ideal for Single Page Applications (SPAs)
- Works entirely on the client side by default
- Needs manual setup for routing, SSR, etc.
In short, React is flexible, but requires more manual effort.
Next.js
Next.js is a React framework that extends React by adding routing, server-side rendering, static generation, and much more – right out of the box.
- Created by Vercel
- Supports both SSR and SSG
- Offers file-based routing and API routes
- Optimized for SEO and performance
- Often used for JAMstack or hybrid sites
In short, Next.js is React with superpowers – especially useful for performance and SEO.
React vs Next.js – Core Differences
| Feature | React | Next.js |
|---|---|---|
| Type | Library | Framework |
| Routing | Manual (react-router-dom) | Built-in file-based |
| Rendering | CSR only | CSR, SSR, SSG, ISR |
| SEO | Manual setup | Built-in support |
| Image Optimization | Manual | Built-in (next/image) |
| API Routes | Not available | Available (/pages/api/) |
| Developer Control | High | Balanced |
Sitecore JSS SDKs – What Are Your Options?
Sitecore’s JSS (JavaScript Services) offering is what enables developers to build fully headless front-end applications that communicate with Sitecore via APIs, mainly the Layout Service. JSS supports multiple front-end frameworks – but they’re not all on equal footing when it comes to features, support, or long-term viability.
Let’s walk through each major option available, with a special focus on their corresponding packages and real-world suitability.
Supported frameworks:
- React
- Next.js
- Angular (legacy support)
- Vue.js (legacy support)
Next.js SDK for Sitecore
Package: @sitecore-jss/sitecore-jss-nextjs
This is Sitecore’s officially recommended SDK for building headless applications – especially when you’re working with Sitecore XM Cloud or public-facing websites that need server-side rendering, SEO, or personalization.
It’s built specifically to work with the Next.js framework and tightly integrates with its rendering strategies like SSR, SSG, and ISR.
Key Features:
- Built-in support for Server-Side Rendering (SSR) and Static Site Generation (SSG)
- Native integration with Experience Editor and Preview Mode
- Works seamlessly with personalization, multilingual/multisite setups, and Experience Edge
- Uses file-based routing, so Sitecore routes map easily to Next.js pages
- Excellent performance with ISR (Incremental Static Regeneration) to update static content on demand
- Supports middleware, API routes, and hybrid rendering patterns out-of-the-box
Ideal for: Content-heavy websites, SEO-focused applications, XM Cloud implementations, and teams that need a balance between performance and editorial flexibility.
React SDK for Sitecore
Package: @sitecore-jss/sitecore-jss-react
This SDK enables you to build headless Sitecore applications using React – without the Next.js framework. It’s typically used with Create React App (CRA), Vite, or any custom React setup.
Unlike the Next.js SDK, this one is designed for client-side rendering (CSR) only. That means you won’t get built-in SSR or SSG unless you integrate additional tools or custom server-side rendering mechanisms.
Key Features:
- Pure React support with no dependency on a specific build tool
- Manual routing setup using react-router-dom or other libraries
- Layout data must be fetched manually using hooks like useEffect
- You handle loading states, errors, and transitions manually
- Limited or workaround-based support for Experience Editor and preview functionality
- Still works well with Sitecore’s Layout Service, component factory, and placeholders
Ideal for: SPAs, internal tools, admin dashboards, or lightweight projects where SEO and editing support aren’t top priorities.
While you can get the job done with this SDK, it requires significantly more boilerplate and configuration compared to Next.js – especially for features like personalization, preview, or SSR.
Angular SDK for Sitecore
Package: @sitecore-jss/sitecore-jss-angular
The Angular SDK allows you to build Sitecore headless applications using Angular. While it still technically works, it’s no longer getting as much attention from Sitecore. Most of the ecosystem and tutorials are focused on React and Next.js.
Key Features:
- Angular support with Sitecore’s Layout Service integration
- Requires more setup to enable routing and layout rendering
- Experience Editor support is possible but less stable than React/Next.js
- Documentation and examples are limited or outdated
Ideal for: Teams heavily invested in Angular with a legacy project that needs to interface with Sitecore in a headless manner. Not recommended for new XM Cloud projects due to limited support and community activity.
Vue SDK for Sitecore
Package: @sitecore-jss/sitecore-jss-vue
Like the Angular SDK, the Vue SDK was created to allow Vue.js developers to build JSS-based front-end apps for Sitecore. However, this SDK is largely legacy and isn’t actively maintained for new capabilities or integrations like personalization or Experience Edge.
Key Features:
- Vue-based rendering of Sitecore Layout Service JSON
- Basic placeholder and component support
- Routing and SSR require additional setup
- Experience Editor integration is limited and clunky
Ideal for: Experimental or legacy Vue-based front ends. Avoid using for XM Cloud or future-facing Sitecore work.
React Native SDK for Sitecore
Package: @sitecore-jss/sitecore-jss-react-native
This experimental SDK is meant to enable mobile applications built in React Native to consume Sitecore layout and content via the Layout Service. While an exciting idea, this SDK is not production-ready and lacks many features you’d expect in a full headless implementation.
Key Features:
- Allows mobile apps to render Sitecore content using components mapped from layout JSON
- No official Experience Editor or personalization support
- Minimal documentation and sample apps
- Not tested against XM Cloud
Ideal for: Prototyping or experimental mobile projects. Not suitable for stable production use.
Next.js vs React SDK: A Comparison
Here’s how the two officially supported Sitecore JSS SDKs stack
| Feature | React JSS SDK | Next.js JSS SDK |
|---|---|---|
| Rendering Support | CSR only | CSR, SSR, SSG, ISR |
| Routing | Manual via react-router-dom | File-based routing |
| SEO | Needs manual setup | Built-in |
| Layout Fetching | Client-side with useEffect | In getStaticProps / getServerSideProps |
| Experience Editor | Limited | Fully supported |
| Preview Mode | Custom setup | Out-of-the-box |
| Personalization | Partial | Full support |
| Performance | Lightweight SPA | Optimized with ISR/SSG |
| Hosting | Static (Netlify, Vercel, Azure Blob) | SSR-capable platforms (Vercel, Azure App Service) |
Final Thoughts
When I first started working with Sitecore headless projects, I’ll admit – I thought Next.js was the only way. It had everything: built-in routing, SSR, Experience Editor support — and it just worked with XM Cloud.
But over time, as I got to work with the React JSS SDK, I realized it brings its own set of strengths. It gives you more control, fewer constraints, and is actually a great fit for lightweight apps, internal tools, or scenarios where SSR isn’t a must-have.
That said, if you’re building a full-blown customer-facing site with personalization, multilingual support, and editorial workflows – Next.js is still the best fit.
So no, it’s not about which one is better. It’s about picking what’s right for your project goals, team setup, and future roadmap. Both SDKs have their place – and knowing when to use what is where the real engineering choice lies.
Source: Read MoreÂ