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.
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.
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.
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
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:
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.