Contributor: Tobias Ouwejan, Frontend Architect

Hybris Commerce was built with a java stack and with this in our DNA, both backend and frontend applications have been built by java framework. For the Storefront we’ve used the (formerly popular) Spring MVC framework and for our business tooling we’ve selected the ZK framework. Logical choices a couple of years back for a company dominated with java geeks. But times have changed… Javascript has entered the tech world and a backend driven frontend doesn’t cut it anymore. Not only because of the technology and customer experience drive, but also to fulfil other challenges, such as upgradability and scalability. Time to select a JavaScript framework!

A few years back, a colleague of mine – Anton – said: “There’s a new JavaScript framework every 5 hours!!”. Anton just wanted to express his disrespect to JavaScript and frontend stuff in general, in a funny way though – to not offend me; I expected nothing less from a backend guy... (joking asides, he’s a great guy). It’s interesting to see that times have changed a lot; where I had to defend myself for years, being a frontend geek, nowadays a whole lot of backend devs like to get their hands dirty with JavaScript. JavaScript is everywhere and the technology and tools are getting more and more mature.

At the time, it must have been 2015, Anton just landed on a Hybris Commerce project which was driven by a frontend team. The team was tasked to do a storefront implementation, but unfortunately got stuck and stopped. There was simply a mismatch between their skillset and our technology stack. The accelerator storefront has been built with Spring MVC and is tightly coupled to our backend Java stack. Moreover, the webservice layer (OCC) wasn’t mature enough to be used as a true headless commerce solution.

A story like this has been one of the motivations to start thinking of a decoupled storefront, written in JavaScript. It took me some time to be bold enough to build a prototype, but I’m happy to share that we are working hard on what we call the JS storefront. There’s a whole lot to talk about on this subject, both on the architecture (modularity, extensibility, configurability, etc.), technology and functional side (i.e. SPA, PWA, CMS integration, etc.). But for now, we start with our JS framework choice: Angular.

AngularJS, Angular 2, ng4?

For those who are new to Angular it’s important to understand the difference to AngularJS. AngularJS was initially build in 2009 at Google and became very popular in the years after. A massive community has contributed to the success. For me it was totally mind-blowing to see one of the early demo’s of AngularFire in 2013, where 3-way data binding was introduced (see figure). Not that AngularJS (or AngularFire in this case) was doing revolutionary things on the web, but now there was a proper framework that allowed to create applications and extend the framework even further.

AngularJS was a great success, but the framework didn’t scale well enough for enterprises applications. Instead of improving the framework, the team at Google decided to do a complete overhaul. This is when Angular was born. Initially called Angular2, or ng2. It took two full years to release Angular 2, and as soon as Google announced version 4 (ng4) as part of an aggressive release plan, it was decided to skip the version number as part of the name. “Angular” was the framework name going forward. Too bad for a whole bunch of ng2- prefixed projects… ngx is the new prefix going forward.

Oh, and by the way, AngularJS has just entered “a 3 year Long Term Support period” in the beginning of this month, which basically means that only production issues (i.e. security) will be patched. If you haven’t jumped on the Angular boat yet, now is the time to leave AngularJS behind. Or select any other great JS framework of course.

⬆ AngularFire using AngularJS in 2013
An early demonstration of AngularFire demonstrated 3-way data binding: two different iFrames on a single page containing the same AngularJS application. The app allows to draw on an html5 canvas (left iFrame) as well as repainting the data from the serverside db (right iFrame), using a realtime json database (Firebase). The drawing data is stored serverside and repainted without any notable delays in another client.

Do we have alternatives?

Absolutely, the purpose of this article is to explain some of the reasons why we chose Angular, but there are great alternatives that might work better for you. I’m actually not writing this post to sum up the differences between the major frameworks at all; it’s been done a dozen of times already – there are several articles on and plenty of others, I rather write about our arguments to use Angular. We’re not so much opinionated about those frameworks and could use different frameworks for different purposes. All of them have stronger and weaker areas.

When Anton made fun of another-framework-every-5-hours, it was a time where MVC-like patterns entered our client-side web applications. A lot of new frameworks popped up all at a sudden, and when a lot of other parts on the web where moving in parallel (i.e. html5, http/2, etc) all at a sudden there was an awful lot of frameworks to choose from. To make it even more complicated, all those frameworks where doing open source, frequent releases, continuous delivery, etc. With a lot of moving parts, it meant that not only a lot of frameworks came out, but each framework would have a lot of frequent releases with a lot of breaking changes. This has caused a lot of headaches, not only to select the right framework, but also to maintain the dependencies (also referred to as NPM hell…). You might wonder why I still like this stuff, huh?

I believe 2017 was the year where the multitude of JS frameworks came to a manageable number. JS land seem to agree on big topics and with that the different choices became smaller. If you’d select a JS framework today, you’d most likely choose between Angular, React or Vue. That being said, there are other valid options that could be considered as well and there will be a new framework sooner then later. Also, it’s not only about the core JS frameworks, there’s a whole bunch of JS and Node.js tools and libraries for developing and building an application.

So, why Angular?

So, enough introduction. Let’s highlight the key arguments for selecting Angular for our JavaScript storefront.

We need a mature framework

An important aspect for building a new JS storefront that will be running for years, is the maturity level of the framework and the organisation behind. Probably all of the major frameworks fulfil this requirement as of today, but we love Angular as it’s been around for such a long time and still renews its core architecture and codebase from release to release. As already stated in the introduction, Google has worked on Angular now for almost a decade. Initially, building AngularJS in 2009 and since 2014 the team developed the new Angular framework. A large number of applications have been built, by Google and by the community. A lot of lessons learnt have been evaluated, and new web standards and concepts have been taken on board, such as web components, server side rendering, PWA techniques, etc.

As you’d expect, there’s a large community that creates libraries on top of the framework. There’s a lot of alignment with the core team. More importantly, multiple initiatives from the community have been taken on board by the Angular teams. This community driven approach has also given a lot of transparency and there’s a lot of stuff to read and listen into, like AngularAir, a Google hangout that gives me good inspiration and fun every Tuesday night.

We don’t mind a large framework

Angular is known because of its arguable size. It’s a large framework with a big footprint and is quite opinionated on how to write and structure your code. This might not be great for super JS experts who know each and every web API from the top of their heads, but for the average SAP Customer Experience (AKA Hybris Commerce) developer JavaScript it’s exactly what we need. Guidance and help from the framework is more than welcome.

The only potential concern of a large framework might be the size of the generated production bundles. The bundle size has been a valid concern with angular for some time, but with proper lazy loading techniques and the upcoming ngIvy in mind (see more on this below), we are absolutely fine.

We love Typescript

One of the most excited things for Hybris Commerce developers I believe is Typescript. JavaScript has been associated with unstructured code, that is painful to develop and causes unexpected runtime errors. Typescript is fixing this; it allows for code completion and code validation and will save development time. Angular has chosen Typescript as their language, but even AngularJS based projects (such as our SmartEdit application) have started to use typescript, even though they haven’t migrated to Angular yet.

Another benefit of Typescript is that you can write in the latest ECMAScript specification. The typescript compiler will transpile to the required JavaScript version, which you can configure. This makes life of developers great, as they can work on the latest and greatest versions of ECMAScript without being concerned about browser adoption.

Other languages, JavaScript supersets or compliers (i.e. coffeescript, dart, babel) have gone on a similar path, but TypeScript seems to be the winner of this game. Well, at least we’re very happy with it!

We expect Dependency Injection

Let’s refer to Angular for an explanation on Dependency Injection (DI):

Dependency Injection (DI) is a way to create objects that depend upon other objects. A Dependency Injection system supplies the dependent objects (called the dependencies) when it creates an instance of an object.

Coming from a Java/Spring background, Dependency Injection (DI) is a no-brainer. DI will help to create clean code, loosely coupled and reusable and will allow for easier testing as well.

The CLI is so useful

The Angular-CLI is the indisputable CLI for Angular and helps our development & build. Just a few reasons:

  • Integrated build system
    Applications and libraries can be build with the CLI, using a number of settings that provides optimised JavaScript bundles. The build system is continuously improved (i.e. library packaging was recently added) and most likely the team will make Bazel a build option in the Angular CLI sooner then later.
  • Helps to structure your project
    Although the structure of an Angular project can be freely setup, the CLI helps out with standard naming conventions of files and the creation of files, unit tests and e2e tests. This is helpful to setup the project in a consistent manner.
  • Extendible through custom scripts
    The CLI has created so-called schematics to further enhance the development with custom scripts. This can be very helpful to generate template-code (which we btw try to avoid completely!), upgrade a project or add a new (custom) component.
  • Integrates new features and techniques
    The CLI does care about modern web applications and have added support for PWA, lazy loading, adding polyfills, etc. All of this helps us to adopt those features in a fast manner.

It’s getting better and better!

When Angular 6 came around last spring, we got a lot of confirmation that we’re on the right path for our JS storefront. A couple of things that we really needed have been introduced in version 6, and with version 7 at the horizon (Q3) it’s getting even better. Let’s touch base on a few of those new items.

Angular Elements

Angular Elements have been introduced in Angular 6. Angular Elements is Angular’s answer to custom elements, one of the key specifications of the web component concept. We’re excited to build web components for our storefront, as it will help to further decouple the components from the application. This decoupling will improve reusability of the components, but most important, it will help to allow for other framework-driven components – more on that below.

However, Angular Elements suffer today from the existing rendering engine in Angular, which has a large footprint. When each and every element would be build and loaded separately, the produced JavaScript bundle would simply be too big. This is the reason why we’re not using Angular Elements as of today, but Angular Ivy (see below) is going to solve this soon.

Angular Ivy

Angular Ivy is the (code?) name for the new render engine in Angular. Initially we’re hoping to have ngIvy as part of Angular 6, but there’s a lot of effort going into the development and we have to wait a little longer; hopefully it will be released as part of Angular 7.

Angular hasn’t been great because of the bundle sizes it generates. With ngIvy in place the amount is reduced massively. Changing the render engine is adding a big risk to existing projects and upgradability. Google however doesn’t want to do any breaking changes and given that they have around 1500 testable applications running on Angular, they’re able to carefully test the render engine before releasing it. That all sounds really promising.


Internationalisation support (Angular I18N) hasn’t been great in Angular so far, well at least when it comes to the localisation of an application. In the standard solution, different locales require a rebuilt of the app for each and every language. This results in production files that contain hardcoded text labels and there’s no way to properly do language-switching. ngx-translate is a third-party library that is fixing all the issues we have with localisation in Angular. And the good news is that Google hired the author to add his work to the Angular standard. That’s exciting, although it does take more time then we like. Therefore we’ll stick to use ngx-translate for the time being until the features have been productised in Angular. Most probably there will be a few breaking changes to fix, but I guess we’re used to that.

Framework Agnostic

But you might not like Angular as much as we do. Although we love Angular and we’re confident that this is the right framework for us, we do appreciate that customers and agencies will have a different taste. Other frameworks have their own strengths and might be better for some projects. Ultimately, we intend to be more framework agnostic.

Web components have an answer to this. Our visionary architecture is a micro-frontend architecture, build by web components. Web components can be implemented by any JS framework that support the custom element specification.

There are a number of hurdles that have to be taken before we can execute on this architecture, but soon enough web components can be part of our extensibility story. Angular is supporting custom elements already, using Angular Elements. Custom elements can be built, but the current size (due to the render engine) is simply not good enough. We’ll wait for ngIvy to be around before we move to this micro-frontend architecture.

What’s next?

So, we’ve made our choice; Angular it is! Let’s see if Anton is eager enough to jump on the bandwagon and gets his head around Angular. Hopefully, we’ve made his life easier by selecting a clear set of technologies, which are here to stay for some time. That being said, there’s will be a new animal in JavaScript land, maybe not in the next 5 hours, but for sure in the next month or so. It might change our mind, let’s see!