At Zalando, autonomy means that every team can make their own technology choices, following our Tech Radar. In conjunction with the approach to use a Microservices architecture, where every service is independent from each other.

Out with the old, in with the new

In 2015, our team Phrasemongers, got new responsibilities. New topics were assigned to us such as search engine advertising and later on customer incentives, which we had to roll up. Therefore, we had to create several small administration frontends, used by only a handful people – a perfect playground to test some of these new technologies.

We decided to completely renew our frontend technology stack, as we were using a stack based on Angular 1, Grunt and RequireJS, the Zalando standard stack that was by now a bit outdated. Our first decision was to use React for future projects, and as our team was the first to switch from Angular to React in Dortmund, we had to start from scratch, reading through documentations and blogs to learn how to code with React and to get a general overview of libraries to use. In contrast to Angular, React is no framework, so nearly every use case in React comes without an integrated toolset (routing, HTTP, etc).

For the first application created with React, we used libraries mainly provided by Facebook – Jest for testing, Flux as application architecture, and Reactify (based on JSTransform and react-tools) to transpile ECMAScript 6 (ES6) to ECMAScript 5 (ES5). As the task runner we chose Gulp, as it reduces boilerplate compared to Grunt and is more performant by working on node streams. To bundle dependencies we choose Browserify, as it is very simple to handle and the boarding corral is not as big as Webpack. Last, but not least, we decided to use plain old jQuery Ajax for handling REST calls.

My first impressions after finishing this application were conflicting: I really appreciated coding with React and JSX (XML-like syntax extension to ECMAScript), but the boilerplate produced with Flux was immense. Other weak points of the technology stack, in my opinion, were Jest and Reactify.

Jest was easy to handle for testing as it mocks every dependency, but the price for it was a performance beneath contempt, even if you limit the number of mocks dramatically. Reactify was a weak point as it only transpiled a limited amount of features from ES6 to ES5, missing for example the let-keyword and the ES6 modules. It was also marked as deprecated by Facebook just when we delivered the application – something a frontend developer stumbles over from time to time.

Better decisions and better results

The next application we started last summer received a slight improvement on the technology stack. After researching alternative Flux implementations, we decided to choose Alt, rated as one of the best alternatives to Facebook's Flux, with radically reduced boilerplate. We also replaced Reactify with Babel, which is somehow the standard for transpiling ES6 to ES5. For the HTTP request library we decided to test SuperAgent along with the ES7 stage 3 feature of async functions, which together made the disliked promise chain easy to handle.

But the best decision we made was to use Webpack instead of Browserify. Browserify was a cool and easy to handle module bundler, but once get familiar with Webpack, you don’t want to go back. With Webpack you can treat nearly everything as a module and bundle it - like CSS- or LESS-files and images - with the concept of Webpack loaders, along with many other incredibly useful features.

As you might suspect, we were far more satisfied with this stack with its various improvements. But for our next application, which we started working on at the beginning of the year, some unexpected changes occurred. In the second half of 2015, an alternative to Flux emerged in Redux. According to the documentation it’s a predictable state container for JavaScript apps. It allows you to track the state over time and therefore restore any state. It’s library is 2 kb in size but also highly extensible. We chose Redux instead of Alt for the next application and also replaced our testing strategy, now using Mocha for lightweight unit tests against a JavaScript dom (jsdom).

We used the Redux-API-Middleware to make HTTP requests, based on the Fetch API as a substitute to the good old XMLHttpRequest, with the advantage being that it is inherently promise based. And, as you don’t really need a task runner anymore by using Webpack, we renounced Gulp, starting tasks only via Webpack or Npm scripts.

While it was a very small application, we managed to put together a technology stack that we are 100% satisfied with it. For our actual frontend project, the fourth programmed with React, we haven’t replaced any library and have improved its whole composition.

And the learning continues!

Team autonomy gives our team the opportunity to experiment with new technologies, gather experiences from backing the wrong horse, collect our learnings, and make a better attempt the next time. With this approach we have a deeper understanding of the libraries we use and we have a stack that perfectly suits our needs.