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

This question comes up in every SAP Commerce Cloud frontend strategy workshop we run. The project team sits down, draws two boxes on the whiteboard. Left box: Composable Storefront, SAP’s own Angular-based headless frontend. Right box: a custom React or Next.js build consuming the same OCC APIs. Then someone asks which one to pick. And the honest answer is always the same — it depends on five things that have nothing to do with framework preference.

Global e-commerce reached $6.3 trillion in 2024, growing 8.4% year-over-year (eMarketer, 2025). Your frontend isn’t a technical detail. It’s the thing your customers touch. It’s where revenue either happens or doesn’t.

TL;DR: SAP Composable Storefront gets you to market faster (8-12 weeks) with 200+ pre-built commerce components, SmartEdit integration, and out-of-the-box SEO. A custom React/Next.js build gives you full design freedom, a larger talent pool, and superior performance tuning — but costs 40-60% more upfront and takes 12-20 weeks. Choose Composable Storefront for standard B2B/B2C, speed, and SAP ecosystem alignment. Choose React/Next.js for differentiated B2C experiences, existing React teams, and long-term flexibility. The hybrid approach — Composable Storefront core with React micro-frontends — often delivers the best of both.

The Decision in 30 Seconds

Pick SAP Composable Storefront if:

• You need to launch fast (under 12 weeks)
• Your use case is standard B2B or B2C commerce
• SmartEdit integration matters to your content team
• Your developers know Angular or can ramp up
• SAP ecosystem alignment is a strategic priority

Pick React/Next.js if:

• UX differentiation is a core competitive advantage
• You already have a strong React/frontend team
• You need pixel-perfect control over every interaction
• Performance optimisation at the edge (ISR, streaming SSR) is critical
• You plan to serve multiple brands or channels from one codebase

Consider a hybrid if:

• You want Composable Storefront’s commerce foundation but need custom experiences for specific pages (PDP, landing pages, configurators)

Architecture Comparison

Both approaches consume the same backend. SAP Commerce Cloud exposes its capabilities through OCC REST APIs. The storefront is a pure API consumer. That decoupling is the whole reason this choice even exists.

Composable Storefront Architecture

Browser → Angular App (Composable Storefront)
           ├── CMS-driven page composition (SmartEdit)
           ├── NgRx state management
           ├── 200+ pre-built commerce components
           └── SSR via Angular Universal
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (Backend)

The storefront ships with components that map directly to Commerce Cloud’s CMS structure. SmartEdit controls layout. Angular Universal handles server-side rendering. The integration is tight and intentional — SAP designed these to work together.

React/Next.js Architecture

Browser → Next.js App
           ├── Custom component library (you build it)
           ├── State management (your choice: Zustand, Redux, etc.)
           ├── SSR / SSG / ISR / Streaming (Next.js built-in)
           └── Headless CMS (Contentful, Storyblok, Sanity, etc.)
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (Backend)

You build the commerce components yourself. You choose your own CMS, state management, and rendering strategy. The OCC APIs are the same. Everything else is yours to decide.

For a deeper look at how Commerce Cloud’s backend layers connect, see our Commerce Cloud architecture guide.

SAP Composable Storefront: What You Get Out of the Box

Composable Storefront (the product formerly known as Spartacus) ships with a substantial amount of pre-built functionality. This is its primary advantage: you start with working commerce, not an empty canvas.

200+ pre-built components. Product listing pages, product detail pages, cart, checkout, my-account, order history, B2B org management, approval workflows, saved carts, quick order. These aren’t demo components. They’re production-ready implementations that map directly to Commerce Cloud’s backend capabilities.

SmartEdit integration. Your content team can rearrange page layouts, swap banners, and manage promotions through SAP’s visual editor without touching code. This matters more than most technical teams admit. For a deep dive on SmartEdit and the CMS architecture, see our Composable Storefront feature guide.

SEO out of the box. Meta tags, canonical URLs, structured data, server-side rendering for crawlability. Not perfect, but functional from day one. You’ll tune it, but you won’t build it.

Internationalisation (i18n). Multi-language, multi-currency, locale-specific formatting. Baked in. Commerce Cloud’s backend handles the content per locale; the storefront renders it.

PWA capabilities. Offline support, home-screen installation, service worker caching. Useful for mobile B2B scenarios where reps work in warehouses with spotty connectivity.

Accessibility (a11y). WCAG 2.1 AA compliance is built into the component library. Keyboard navigation, ARIA labels, focus management. Not flawless, but a real starting point versus building from scratch.

The catch: it’s Angular. If your team knows React and doesn’t know Angular, the learning curve is real. NgRx state management is verbose compared to modern React state libraries. And Angular Universal’s SSR isn’t as mature as Next.js for complex rendering strategies.

React/Next.js: What You Build Yourself

Choosing React/Next.js means choosing freedom — and responsibility. Here’s what Next.js gives you that Composable Storefront doesn’t, and what you’ll need to build on your own.

Server-Side Rendering, done better. Next.js 15 supports static generation (SSG), server-side rendering (SSR), incremental static regeneration (ISR), and streaming with React Suspense. You can mix strategies per route. A product listing page can be statically generated and revalidated every 60 seconds. A cart page can be fully dynamic. This granularity doesn’t exist in Composable Storefront’s Angular Universal approach.

Image optimisation. Next.js Image handles responsive sizing, lazy loading, format conversion (WebP/AVIF), and CDN integration automatically. Commerce sites are image-heavy. This adds up.

Edge runtime. Deploy to Vercel, Cloudflare Workers, or AWS Lambda@Edge. Run rendering logic close to the user. Composable Storefront’s SSR runs on a Node.js server — no edge deployment option.

React Server Components. Reduce client-side JavaScript by moving data fetching and rendering to the server. Ship less JS to the browser. Faster Time to Interactive.

Ecosystem breadth. Headless CMS options (Contentful, Storyblok, Sanity, Builder.io), component libraries (Radix, shadcn/ui), animation (Framer Motion), testing (Playwright, Testing Library) — the React ecosystem is massive.

What you build yourself: every commerce component. PLP, PDP, cart, checkout, my-account, B2B flows, saved carts, approval workflows. You’ll consume the same OCC APIs, but you write every component, every API integration, every state management pattern. That’s 200+ components that Composable Storefront ships for free.

For a broader perspective on headless and composable patterns, our headless vs composable commerce explainer covers the strategic thinking behind these architectures.

Feature Comparison

Performance Comparison

Performance is where the React/Next.js argument gets compelling. When done right.

Core Web Vitals. Composable Storefront delivers decent scores out of the box. Typical Lighthouse performance sits at 70-85 for a standard implementation. The Angular bundle is heavier than a well-optimised React app, and Angular Universal’s hydration adds overhead. A tuned Next.js build with React Server Components, streaming SSR, and edge rendering routinely hits 90+ on Lighthouse. That’s a meaningful gap for consumer-facing storefronts. Google confirmed that Core Web Vitals remain a ranking signal and merchants with faster sites see 15-20% higher conversion rates (Google Web.dev, 2024).

First Contentful Paint (FCP). Composable Storefront: 1.5-2.5s typical. Next.js with SSG/ISR: 0.5-1.2s typical. The difference comes from static generation — Next.js can serve pre-built HTML from a CDN without waiting for a server render.

Largest Contentful Paint (LCP). Product detail pages with heavy imagery are the test. Next.js Image with priority loading and format negotiation consistently outperforms Angular’s approach. Savings of 0.5-1.5 seconds are common.

Total Blocking Time (TBT). Angular’s change detection and NgRx state management add more main-thread work than a lean React setup. React Server Components specifically target this by moving rendering off the client.

The caveat. A badly built Next.js site performs worse than a well-configured Composable Storefront. These numbers assume competent implementation on both sides. 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. It’s often the decisive one.

The 2025 Stack Overflow Developer Survey places React as the most popular web framework, used by 39.5% of professional developers, while Angular sits at 17.1% (Stack Overflow, 2025). That’s a 2.3x gap in the developer talent pool.

What this means in practice:

• Hiring. A React frontend developer role attracts roughly twice the applicants as an equivalent Angular role. In competitive markets (Zurich, Munich, London), this matters.
• Salaries. Specialised Angular developers with SAP experience command a premium. React developers are more available, which keeps market rates more competitive.
• Contractor availability. If you need to scale up quickly with external contractors or agencies, the React pool is substantially deeper.
• Knowledge transfer. New team members ramp up faster on React projects because they’re more likely to have prior experience.

The counterargument. Angular developers tend to be more experienced 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

Real numbers from comparable Commerce Cloud frontend projects. These assume a standard B2B or B2C storefront with 50-100 products, standard checkout, multi-language, and integration with one payment provider.

The nuance. React/Next.js costs more upfront and in year one. But if you’re running multiple storefronts, the shared component library amortises across properties. By year three, a well-managed React component library serving three storefronts can cost less per-storefront than three separate Composable Storefront customisations.

The Hybrid Approach

Here’s what we’ve been recommending more often in 2025 and 2026: use both. Not in a messy way. Strategically.

The pattern: Composable Storefront handles the core commerce journey — product listing, product detail, cart, checkout, my-account. It’s where the 200+ components earn their keep. Then you build specific high-impact experiences in React and mount them as micro-frontends within the storefront shell.

Where React micro-frontends fit:

• Product configurators. Complex 3D configurators or custom product builders where React’s component model and ecosystem (Three.js, React Three Fiber) have a clear edge.
• Landing pages. Campaign-specific pages with custom animations, interactive storytelling, or content-heavy layouts where design freedom matters most.
• Mobile apps. React Native shares component logic with your web React code. Composable Storefront doesn’t have a native mobile story.
• Personalisation engines. Real-time recommendation widgets or AI-driven experiences built with streaming React Server Components.

How it works technically: SAP 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 alongside standard Composable Storefront components. The micro-frontend loads independently, communicates with the parent via custom events or a shared state bus.

This approach gets you 80% of Composable Storefront’s time-to-market advantage while preserving React’s flexibility where it matters most.

Decision Framework

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

1. What’s your timeline? Under 12 weeks to go-live? Composable Storefront. The pre-built components and SmartEdit integration save 4-8 weeks versus a custom build. No amount of React talent compensates for that when time is the constraint.

2. What does your team know? Existing Angular team with SAP experience? Composable Storefront. Existing React team with no Angular experience? React/Next.js. The retraining cost is real: 2-3 months of reduced productivity while developers learn a new framework, state management pattern, and testing approach. Mixed team? Consider the hybrid.

3. Is the storefront a brand differentiator or a functional tool? B2B ordering portal, customer self-service, reorder functionality? Composable Storefront handles this with minimal customisation. Consumer-facing brand experience where every interaction is designed? React/Next.js gives you the pixel-level control. The distinction matters. Most B2B storefronts are functional tools. Most ambitious B2C experiences are brand differentiators.

4. How important is SmartEdit? If your marketing team needs to manage content, layouts, and promotions without developer involvement, SmartEdit integration is a significant advantage. Replicating this with a headless CMS (Contentful, Storyblok) works, but it’s a separate system with its own learning curve, licence cost, and integration work.

5. What’s your 3-year plan? Single storefront, stable requirements, SAP ecosystem investment? Composable Storefront’s SAP-aligned roadmap is an asset. Multiple storefronts, rapid frontend evolution, potential framework migration? React/Next.js with a shared component library gives you more flexibility.

What We See in Practice

Over the past three years, we’ve delivered Commerce Cloud frontends using both approaches. The pattern is clear: Composable Storefront wins on speed and cost for standard commerce. React/Next.js wins on flexibility and performance for differentiated experiences. The hybrid wins when you need both.

The mistake we see most often: choosing React/Next.js because the team “prefers React” and then spending 16 weeks rebuilding components that Composable Storefront ships out of the box. Framework preference is valid. But it shouldn’t cost you CHF 100,000 in duplicated effort.

The second most common mistake: choosing Composable Storefront and then fighting Angular for 6 months to build a highly custom experience that React would handle natively. If your design team hands you Figma files that look nothing like a standard storefront, Composable Storefront’s components become a constraint, not an accelerator.

Match the tool to the job. Not the other way around.

Need help deciding? We run frontend architecture assessments for SAP Commerce Cloud that evaluate your team, timeline, and requirements — then recommend the approach that delivers value fastest. Talk to our commerce architects.

For more on SAP Commerce Cloud capabilities, visit our E-Commerce solution page.

Frequently Asked Questions

Is SAP Composable Storefront the same as Spartacus?

Yes. SAP rebranded Spartacus to “SAP Composable Storefront” in 2023. Same product, same Angular codebase, same Commerce Cloud OCC API integration. The name changed; the technology didn’t. Most developers still call it Spartacus in conversation. SAP’s documentation now uses “Composable Storefront” exclusively.

Can I use React with SAP Commerce Cloud?

Yes. Commerce Cloud exposes OCC (Omni Commerce Connect) REST APIs that any frontend framework can consume. React, Next.js, Vue, Svelte — anything that can make HTTP requests works. The OCC API layer is framework-agnostic by design. You lose SmartEdit’s visual page editor and the pre-built commerce components, but you gain full control over the frontend architecture.

Which approach is faster to implement?

Composable Storefront is faster for standard B2B/B2C scenarios: 8-12 weeks versus 12-20 weeks for a custom React/Next.js build. The 200+ pre-built components, SmartEdit integration, and existing Commerce Cloud CMS mapping save significant development time. The gap narrows for highly custom experiences where Composable Storefront’s components need heavy modification anyway.

Which approach is more expensive?

Custom React/Next.js is 40-60% more expensive upfront because you build every commerce component from scratch. You also need a separate headless CMS licence (CHF 6,000-24,000/year). Composable Storefront includes SmartEdit and the component library. Over three years, the cost difference narrows if you’re running multiple storefronts with a shared React component library — but for a single storefront, Composable Storefront is consistently cheaper.

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

Angular is not dying. It’s backed by Google, sees active development (Angular 18 shipped with signal-based reactivity), and has a large enterprise user base. That said, React’s talent pool is 2.3x larger by developer survey data. This affects hiring speed and contractor availability, not the framework’s viability. If you already have Angular developers, there’s no reason to switch. If you’re building a team from scratch, React’s larger talent pool is a practical advantage.