Contributor: Tobias Ouwejan, Frontend Architect
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.
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 medium.com 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?
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
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
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
- 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 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.
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.
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.