Frontend Architecture for Design Systems

Part V. The Documentation Pillar

Let’s face it: our frontend code is getting more and more complex with every project we start. I’m not saying this is a bad thing, it’s just that this rapid rate of growth comes with its own set of growing pains.

Just a few years ago all of our CSS was written in a single file, and each style used a long complex selector to find just the right element on the page to modify. If we found that this style was interfering with something else on our site, we just wrote another line of CSS at the bottom of the file with a longer selector.

In the same way, our JavaScript file was written using a bunch of jQuery functions targeting preexisting markup and applying some functionality to it. Each function would contain every bit of logic and processing required to get the job done. If we needed to write a slightly modified version of this functionality for another element, it was always easier to just duplicate the code, change the selector, and update the logic.

We were writing the equivalent of a single-file PHP application for every project.

Then, just as new PHP developers are taught to break up their code into small reusable objects and to organize their code into individual files, our frontend projects started to look less like a cascade of instructions and more like a complex system of abstraction, dependencies, and interfaces. But while we were quick to incorporate the object-oriented, multi-file approach of traditional programing languages, we were ...