SAP Composable Storefront vs React/Next.js: When to Choose What

This question comes up in every SAP Commerce Cloud front-end workshop we run. On the left of the whiteboard: the SAP Composable Storefront, SAP’s own Angular-based headless front end. On the right: a custom React or Next.js build that consumes the same OCC APIs. The answer depends on five factors, and framework preference is not one of them.

TL;DR: The SAP Composable Storefront gets you to market faster (roughly 8 to 12 weeks for a typical storefront) with a large library of pre-built commerce components, SmartEdit integration and server-side rendering included. A custom React/Next.js build gives you full design freedom, more rendering options and a larger talent pool, but typically costs 40 to 60 percent more to build and takes 12 to 20 weeks. Choose the Composable Storefront for standard B2B and B2C, speed and SAP alignment; choose React/Next.js for differentiated B2C experiences and existing React teams. A hybrid (Composable Storefront core with React micro-frontends) often combines both.

The decision in 30 seconds

Pick the SAP Composable Storefront if:

• You need to launch fast (under 12 weeks).
• Your use case is standard B2B or B2C commerce.
• SmartEdit matters to your content team.
• Your developers know Angular or can learn it.
• Alignment with SAP’s roadmap is a priority.

Pick React/Next.js if:

• A distinctive user experience is a core competitive advantage.
• You already have a strong React team.
• You need full control over every interaction.
• Edge rendering and incremental static regeneration matter to you.
• You plan to serve several brands or channels from one component library.

Consider a hybrid if you want the Composable Storefront’s commerce foundation but need custom experiences for specific pages such as product configurators or campaign pages.

Architecture comparison

Both approaches use the same back end. SAP Commerce Cloud exposes its functions through the OCC REST APIs, and the storefront is a pure API consumer. That decoupling is the reason this choice exists at all.

Composable Storefront

Browser → Angular app (Composable Storefront)
           ├── CMS-driven page composition (SmartEdit)
           ├── NgRx state management
           ├── Pre-built commerce components
           └── Server-side rendering (Angular SSR on Node.js)
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (back end)

The storefront’s components map directly to Commerce Cloud’s CMS structure, SmartEdit controls the layout and Angular’s server-side rendering produces the first page. SAP designed these parts to work together (SAP Help: About Composable Storefront).

React/Next.js

Browser → Next.js app
           ├── Custom component library (you build it)
           ├── State management (your choice: Zustand, Redux ...)
           ├── SSR / SSG / ISR / streaming (built into Next.js)
           └── Headless CMS (Contentful, Storyblok, Sanity ...)
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (back end)

You build the commerce components yourself and choose your own CMS, state management and rendering strategy. The OCC APIs are the same; everything else is your decision. For the back-end layers behind the APIs, see our SAP Commerce Cloud overview.

SAP Composable Storefront: what you get out of the box

The Composable Storefront (formerly Spartacus) ships with a substantial amount of working functionality. That is its main advantage: you start with working commerce, not an empty canvas.

Pre-built commerce components. Product lists and detail pages, cart, checkout, my account, order history, B2B organisation management, approval workflows, saved carts, quick order. These are production components mapped to Commerce Cloud’s back-end functions, not demos.

SmartEdit integration. Your content team rearranges layouts, swaps banners and manages promotions in SAP’s visual editor without touching code. This matters more than most technical teams admit. Our Composable Storefront guide explains the CMS architecture in detail.

SEO from day one. Meta tags, canonical URLs, structured data and server-side rendering for crawlers. You will tune it, but you will not build it.

Internationalisation. Multiple languages and currencies and locale-specific formatting, with the content per locale coming from the back end.

PWA features. Offline support, installation on the home screen, service-worker caching. Useful for B2B scenarios with weak connectivity, such as field staff in warehouses.

Accessibility. The components are built with keyboard navigation, ARIA labels and focus management. Not flawless, but a real starting point compared with building from scratch.

The catch: it is Angular. If your team knows React and not Angular, the learning curve is real. NgRx is more verbose than modern React state libraries, and Angular’s server-side rendering offers fewer rendering strategies per route than Next.js. SAP moves the storefront to a new Angular major version once a year, in February; the 2211.36 release, for example, moved to Angular 19 and Node.js 22.

React/Next.js: what you build yourself

React/Next.js means freedom and the responsibility that comes with it.

More rendering options. Next.js supports static generation (SSG), server-side rendering (SSR), incremental static regeneration (ISR) and streaming with React Suspense, and you can mix them per route. A product list can be generated statically and revalidated every minute while the cart stays fully dynamic.

Image optimisation. Next.js handles responsive sizing, lazy loading, format conversion (WebP, AVIF) and CDN delivery. Commerce sites are image-heavy, so this adds up.

Edge runtime. Deploy to Vercel, Cloudflare Workers or AWS Lambda@Edge and render close to the user. The Composable Storefront’s SSR runs on a Node.js server; SAP does not provide an edge-rendering option for it.

React Server Components. Data fetching and rendering move to the server, so less JavaScript reaches the browser.

Ecosystem breadth. Headless CMS options, component libraries (Radix, shadcn/ui), animation and testing tools. The React ecosystem is very large.

What you build yourself: every commerce component. Product lists, detail pages, cart, checkout, my account, B2B flows, saved carts, approval workflows. You use the same OCC APIs, but you write every component, every API integration and every state pattern that the Composable Storefront ships ready-made. For the broader architecture debate, see our post on composable commerce in B2B.

Feature comparison

Dimension	Composable Storefront	React/Next.js
Time to market	Roughly 8 to 12 weeks (typical B2B/B2C)	12 to 20 weeks
Pre-built commerce components	Large library, production-ready	Build from scratch
SmartEdit / CMS	Native integration	Headless CMS needed (extra cost and integration)
SEO	SSR, meta tags, canonical URLs built in	More options: SSG, ISR, edge SSR, streaming
Core Web Vitals	Good with standard tuning	Excellent when well optimised
Rendering strategies	SSR (Angular)	SSR, SSG, ISR, streaming, edge
Talent pool	Smaller (Angular)	Larger (React)
Customisation ceiling	High, within Angular patterns	Unlimited
Mobile / PWA	PWA features built in	PWA set up manually, React Native option
Accessibility	Accessible components as a baseline	Build your own (or use Radix, Headless UI)
State management	NgRx (included)	Your choice (Zustand, Redux, Jotai)
SAP alignment	Full: SAP roadmap, support, patches	None: you own everything
CDN / edge deployment	Node.js server	Vercel, Cloudflare, AWS edge
Upgrade path	SAP-managed releases	Framework and your code: you manage it
Initial build cost	Lower	Typically 40 to 60 percent higher

Performance comparison

Performance is where the React/Next.js argument becomes compelling, when it is done well.

Core Web Vitals. The Composable Storefront delivers decent results out of the box. The Angular bundle is heavier than a well-optimised React application, and hydration adds work. A carefully tuned Next.js build with React Server Components, streaming and edge rendering can go further. For consumer-facing storefronts that gap matters, because Core Web Vitals are part of the signals Google Search uses to assess page experience.

First paint. Static generation lets Next.js serve pre-built HTML from a CDN without waiting for a server render, which usually shortens the first contentful paint noticeably.

Largest Contentful Paint. Image-heavy product detail pages are the real test. Next.js image handling with priority loading and format negotiation tends to perform better than a standard Angular setup.

Main-thread work. Angular’s change detection and NgRx add more work on the main thread than a lean React setup; React Server Components specifically reduce it.

The caveat. A badly built Next.js site performs worse than a well-configured Composable Storefront. The React ecosystem gives you more performance levers, but you have to pull them.

The talent factor

This is the factor most architecture documents skip, and it is often the decisive one.

In the 2024 Stack Overflow Developer Survey, 39.5 percent of respondents used React and 17.1 percent Angular (Stack Overflow Developer Survey 2024), a gap of more than two to one.

What that means in practice:

• Hiring. React roles typically attract considerably more applicants than comparable Angular roles, which matters in tight markets such as Zurich or Munich.
• Rates. Angular developers with SAP experience command a premium; React developers are more available.
• Contractors. If you need to scale up quickly with external developers, the React pool is much deeper.
• Onboarding. New team members are more likely to know React already.

The counterargument. Angular developers are often more at home with enterprise patterns (dependency injection, typed services, RxJS). If your team already knows Angular, switching to React to follow a market trend is expensive and risky. Use what your team knows.

Cost comparison

Indicative planning ranges for a standard B2B or B2C storefront with a moderate catalogue, standard checkout, several languages and one payment provider. They are estimates for orientation, not quotes.

Cost category	Composable Storefront	React/Next.js
Initial build	CHF 120’000 to 180’000	CHF 180’000 to 300’000
Headless CMS licence	Included (SmartEdit)	CHF 6’000 to 24’000 per year
Annual maintenance (development)	CHF 40’000 to 60’000 (1 to 2 developers)	CHF 60’000 to 100’000 (2 to 3 developers)
SAP licence	Included in Commerce Cloud	Included in Commerce Cloud
Hosting / CDN	Node.js server on SAP Commerce Cloud	Vercel/Cloudflare (CHF 2’400 to 12’000 per year)
Three-year total	CHF 240’000 to 360’000	CHF 370’000 to 600’000

The nuance. React/Next.js costs more up front and in the first year. With several storefronts, however, a shared component library spreads its cost across properties, and by year three it can cost less per storefront than several separately customised Composable Storefronts. For the full platform budget, see our SAP Commerce Cloud pricing and TCO guide.

The hybrid approach

What we have recommended more often since 2025: use both, deliberately.

The pattern: the Composable Storefront handles the core commerce journey: product lists, product details, cart, checkout, my account. That is where its pre-built components pay off. Selected high-impact experiences are built in React and mounted as micro-frontends inside the storefront shell.

Where React micro-frontends fit:

• Product configurators. 3D configurators or custom product builders, where React’s ecosystem (Three.js, React Three Fiber) has a clear edge.
• Campaign pages. Pages with custom animation, interactive storytelling or content-heavy layouts where design freedom matters most.
• Mobile apps. React Native shares logic with your web React code; the Composable Storefront has no native mobile app of its own.
• Personalisation. Real-time recommendation widgets or AI-driven experiences.

How it works technically: Commerce Cloud’s CMS supports custom components. You register a React micro-frontend as a CMS component, and SmartEdit can place it on any page next to standard components. The micro-frontend loads independently and communicates with the shell through custom events or a shared state channel.

This keeps most of the Composable Storefront’s time-to-market advantage while preserving React’s flexibility where it matters.

Decision framework

Work through these five questions in order. Each one narrows the choice.

1. What is your timeline? Under 12 weeks to go-live: the Composable Storefront. Its components and SmartEdit integration save several weeks against a custom build, and no amount of React talent makes up for that when time is the constraint.

2. What does your team know? An Angular team with SAP experience: Composable Storefront. A React team without Angular: React/Next.js. Retraining is real: expect a few months of reduced productivity while developers learn a new framework, state pattern and testing approach. A mixed team: consider the hybrid.

3. Is the storefront a brand differentiator or a functional tool? B2B ordering portals, customer self-service and reordering are handled by the Composable Storefront with little customisation. A consumer brand experience where every interaction is designed calls for React/Next.js. Most B2B storefronts are functional tools; most ambitious B2C experiences are brand differentiators.

4. How important is SmartEdit? If marketing needs to manage content, layouts and promotions without developers, SmartEdit is a significant advantage. A headless CMS can replace it, but that is another system with its own learning curve, licence and integration work.

5. What is your three-year plan? A single storefront, stable requirements and investment in SAP: the Composable Storefront’s SAP-aligned roadmap is an asset. Several storefronts, rapid front-end change or a possible later framework move: React/Next.js with a shared component library gives you more room.

What we see in practice

We have delivered Commerce Cloud front ends with both approaches. The pattern is consistent: the Composable Storefront wins on speed and cost for standard commerce, React/Next.js wins on flexibility and performance for differentiated experiences, and the hybrid wins when you need both. At Distrelec, decoupling the front end from SAP Commerce through a clean API layer cut time to market by 70%.

The mistake we see most often: choosing React/Next.js because the team prefers React, then spending months rebuilding components the Composable Storefront ships out of the box. Framework preference is legitimate, but it should not cost six figures in duplicated effort.

The second most common: choosing the Composable Storefront and then fighting Angular for months to build a highly custom experience that React would handle more naturally. If your design team hands over designs that look nothing like a standard storefront, the storefront’s components become a constraint rather than an accelerator.

Match the tool to the job, not the other way round. If the storefront decision is part of a larger project, our post on what actually happens in a Commerce Cloud implementation puts it in context.

---

Need help deciding? We run front-end architecture assessments for SAP Commerce Cloud that look at your team, timeline and requirements and recommend the approach that delivers value fastest. Talk to our commerce architects. More on our Commerce Cloud work is on the SAP Commerce Cloud solution page.

Frequently asked questions

Is SAP Composable Storefront the same as Spartacus?

Yes. From release 5.0, SAP publishes the official Spartacus libraries as “SAP Commerce Cloud, composable storefront”. It is the same Angular code base and the same OCC API integration; since version 2211.19 its version numbers follow Commerce Cloud. Many developers still say Spartacus; SAP’s documentation uses Composable Storefront.

Can I use React with SAP Commerce Cloud?

Yes. Commerce Cloud exposes the OCC (Omni Commerce Connect) REST APIs, which any front-end framework can consume: React, Next.js, Vue and others. You give up SmartEdit’s ready-made page rendering and SAP’s pre-built commerce components, and gain full control over the front-end architecture.

Which approach is faster to implement?

The Composable Storefront is faster for standard B2B and B2C scenarios: roughly 8 to 12 weeks for a typical customised storefront, against 12 to 20 weeks for a custom React/Next.js build. The pre-built components and the existing CMS mapping save most of that time. The gap narrows for highly custom experiences where the standard components need heavy modification anyway.

Which approach is more expensive?

A custom React/Next.js front end typically costs 40 to 60 percent more to build, because every commerce component has to be written and a separate headless CMS is usually needed. The Composable Storefront is included in the Commerce Cloud licence and costs less to build, but can need heavy customisation for a very distinctive user experience. Over three years the difference narrows if several storefronts share one React component library; for a single storefront, the Composable Storefront is usually cheaper.

Is Angular dying? Should I worry about the Composable Storefront’s framework?

No. Angular is backed by Google, ships a major release every six months and is widely used in enterprises; SAP moves the storefront to a new Angular version once a year. React does have a larger talent pool, which affects hiring and contractor availability rather than the framework’s viability. If you already have Angular developers, there is no reason to switch; if you are building a team from scratch, React’s larger talent pool is a practical advantage.