The rebirth of the wehkamp front-end
It feels like only yesterday when you sat down at home after school behind your computer, staring at the screen and just, patiently, waiting for this typical sound.
It was in that period of time — about 1995 — when wehkamp, like many others, wanted to expand their offline business proposition to this new platform, promising infinite possibilities.
Being this pioneer online and having to deal with all the hardware restrictions and lack of decent broadband internet connections we are used to nowadays, wehkamp offered their customers only the slimmed-down interface online, while all catalog imaging was sourced from a CD-ROM that was ordered earlier.
A lot has changed since then.
That slimmed-down interface evolved into something that matches the need of a modern customer. A rich user experience with interactive marketing content and a high-performant and responsive platform to accommodate a wide range of devices.
Although the current platform is very successful, a new and more flexible way of developing for the future was needed. Things needed Blaze. So did the front-end.
Just working with HTML, CSS and jQuery
The front-end stack of the current wehkamp.nl platform consists of just working with HTML, CSS and jQuery. And the luxury of having one of the most extensive IDE’s you can ask for as a developer in the .NET stack: Microsoft Visual Studio. As all functionality was built on premise and being stored within Team Foundation Server, we were our own resource community.
Although we saw the need to componentize the front-end codebase in it’s current state, the size of the platform made it a herculean task to do. From several parts of the code-base, tens of stylesheets and even more javascript includes were done and CSS specificity was a real struggle.
Serving millions of users per day, you need to be fast. And since a stylesheet is on the critical path, we were aiming to reduce the amount of stylesheets drastically. Components were being rearranged, lots of code was combined, legacy declarations were removed and a new bundling tool powered by the Web Essentials plugin in Visual Studio was introduced. The result: less HTTP-request, less server-load, not twelve but only three separate stylesheets in the DOM, and a much easier way to work with the code-base provided.
But that was not the end of it. When we started out with Blaze for wehkamp.com, we knew we had to stretch it even further. Modern web development is all about finding the right tools, and get the most out of every project. The choice of the toolset began very low-level. As the fundamentals with the Typesafe stack were a fact for the backend, and had Github as version control system, we chose the Yeoman scaffolding tool to set up the front-end basics.
AngularJS as weapon of choice
To accommodate user interaction in a flexible and scalable platform to handle our HTML rendering and DOM manipulation we had AngularJS as weapon of choice. In contrast to the old stack and doing everything manually with the jQuery library, AngularJS is a mature framework where a lot of functionality comes out-of-the-box like routing, two-way data binding and dependency management. Yes, the word ‘framework’ implies rigidity, but the fact that you are forced to have a certain project architecture, decreases the risk of clutter and personal code-style which could lead to a higher learning curve across the teams.
We needed a solid build-tool to deliver high-quality, concatenated, minified and versioned software. For us that was Grunt. Apart from the build tasks, day-to-day coding is like a breeze with all changes being automatically live-reloaded in the browser.
The mind-set of quality without compromise was incorporated within right from the start of the project. And with that criteria aiming to be met, a solid testing framework is a necessity. Karma — which is seamlessly integrated with Grunt — for the unit-testing, and Protractor and BrowserStackfor the end-to-end and multi-browser testing.
Taming large-scale CSS
For the interface part, in which CSS played a major role, we did not have anything in place, other that the Sass preprocessor to streamline it. But what about project structure? How do we shape our stylesheets so that we can meet our business’ wishes?
In essence, the language of the Cascading Style Sheet is not very dynamic. It is quirky, it doesn’t let itself shape easily and every browser has its own way of treating it.
So we needed a plan. In the year prior to Blaze, the front-end team spent an awesome week together with Harry Roberts here at wehkamp. We talked about the process of creating, maintaining and engineering large-scale CSS and how we could let it work for us, instead of against us. Harry introduced us to his latest methodology: ITCSS.
The inverted triangle
ITCSS, short for “Inverted Triangle CSS”, is a scalable, managed architecture for working with CSS at progressive scale. It is a methodology and school of thought which allows us to strictly group and order explicit types of CSS rules in a manner that makes them more useful, more manageable and more extensible. ITCSS is a meta-framework which aims to guide and outline a project’s architecture; it does not dictate anything as specific as naming conventions, or any other more opinionated ideas.
The Inverted Triangle aims to tame and guide the aspects of CSS that become problematic at scale — specificity, inheritance, and the cascade. Layers toward the top affect a lot of the DOM, are very far reaching, have a lower specificity, and have a lot of cascading rules. As we travel down the layers in the triangle, we find that rules affect less and less of the DOM, have a progressively higher specificity, and pass on less and less of their styling to subsequent layers.
The key to breaking code into these shearing layers is by structurally and visually decomposing UI features. If a new design is being made, we need to work out what aspects of it can be attributed to a certain layer. To make sure the component based architecture is being preserved, element repetition or the potential for element repetition must be addressed. Reusable interface features help maintaining the codebase and reduce its growth. And that automatically means working together closely with other team-members and stakeholders, because modern web development is still just a way to build the stuff right. But let’s not forget to build the right stuff.
Spiffy interface
As the fast-growing and ever changing technological landscape of the new e-commerce platform of wehkamp is evolving, so does its user interface. We are constantly shaping, expanding and perfecting our components to provide not only a spiffy interface, but more importantly, one that just works intuitively and leaves no questions to the individual who uses it.
The past year at wehkamp has been a real rollercoaster of new tools and techniques. And let’s face it: a new JavaScript framework is released practically each month in the community. A challenge, but one that grew with us and really made us accelerate. Choices about which tool or library to use on our project go hand in hand with the transition we face as a team. But we are not in it alone. Since Blaze and the new tech-stack, the open-source community has our back too. And that evolution pays off. The Blaze front-end has really been reborn.
This entry was originally posted on wehkamplabs.com
