Throughout this article I will analyse and compare the main advantages Spartacus offers over the legacy SAP Commerce B2C accelerator and the SAP Commerce B2B accelerator, particularly from a developer experience point of view.

SAP Commerce Cloud (formerly SAP Hybris Commerce Cloud) is a cloud-native omnichannel commerce solution for B2B, B2C, and B2B2C companies.

Spartacus is an Open Source, Angular-based JavaScript storefront for SAP Commerce meant to replace the legacy Commerce Cloud Accelerator. Spartacus is still under development and version 2.1.0 has recently been released.

First of all, let us take a look at the tech stack:

SAP Commerce B2C accelerator, SAP Commerce B2B accelerator: Spring MVC, jQuery, LESS, Grunt.

Spartacus: Angular 10 (TypeScript), ngrx, Sass, Jasmine with Karma as test runner, Cypress for E2E tests.

Typescript provides type safety thus avoiding runtime errors. It also adds IDE auto completion. NgRx provides reactive state management for Angular apps inspired by Redux. This provides a single source of truth and side effect management, which prevents state inconsistencies and bugs. It helps with predictability, flexibility and makes debugging easier with tools like the Redux DevTools.

Moreover, Angular is a component based framework, meaning that each component has its own encapsulated logic and styling as well as its own unit tests. Since the SAP Commerce B2C accelerator and SAP Commerce B2B accelerator were not component-based, namespaces had to be used to avoid namespace pollution, namely in the global ACC namespace. Despite this, a jQuery event listener from page A could be mistakenly added to page B, for instance by accidentally using the same selector, causing unpredictable behaviour potentially leading to bugs.

This was also an issue with CSS, where selector specificity and uniqueness was left to the opinionated choice of the developer (BEM, OOCSS, etc), potentially leading to bugs as well.

Generally speaking, it is not a library or framework change but a whole mindset shift, since Angular is a fully-fledged framework which includes a development server and an extremely popular community and ecosystem for modern JS development while jQuery is a library that allows us to mutate the DOM and interact with the tightly coupled Spring back end.

Furthermore, Spartacus is a Single-page application (SPA), which is a web app implementation that loads only a single web document, and then updates the body content of that single document via JavaScript APIs such as XMLHttpRequest and Fetch when different content is to be shown.

This is a major difference when compared to the legacy storefront, which is a Multi-Page Application (MPA). It means that each page is reloaded every time the user interacts with the site requesting some data, even if only a tiny part of the UI needs to be updated. An in-depth comparison can be read here.

Since there is no mechanism in place to prevent it, every single JavaScript file is loaded at any time, despite the fact that it might not be needed (e.g. acc.storefinder.js, the store finder jQuery code, or the product detail JavaScript at the FAQ page), cluttering the front end with unnecessary event listeners. The same happens with dead code, code that is not used at all (i.e. as a result of an error during a refactor or a merge) but gets shipped to production, resulting in a suboptimal JS bundle.

Angular handles this for Spartacus on build time, making use of tree-shaking and limited dead code elimination. More precisely, webpack does this under the hood when the –prod flag is provided to ng build. Lazy loading is also an interesting topic recently introduced in Spartacus. For instance, lazy loadable components and modules are now supported in CMS mapping and will shortly be used on the B2B feature.

Spartacus is also a Progressive Web App, this can be tested locally running yarn start:pwa.

Finally, from an architectural point of view, Spartacus achieves upgradability and extendibility using libraries, which are maintained and updated independently and can be used separately:

• • core

• • storefront

• • styles

• • schematics

• • cds

Libraries are published on npm and a storefront can be built from these libraries. This is in contrast to the legacy storefront, where the main instruments to achieve modularity were add-ons and styles were tightly coupled to the storefront extension, which in turn was also coupled to the back end as a whole.

In summary, Spartacus provides a modern JavaScript storefront for SAP Commerce Cloud, having a significant positive impact on developer experience and productivity by leveraging the latest technologies and using cutting-edge development and testing tools.

Excited to start using Spartacus? Take a look at the roadmap, check out the documentation, Slack channel, Stack Overflow, take the free introductory routing course and feel free to contribute!