Frontend Architecture for Design Systems

Part II. The Code Pillar

Good code never happens by accident. It’s not that developers are inherently lazy, or that we cannot be trusted, but left to our own devices, we are capable of producing a wide variety of solutions to the same problem. Unlike a trip through a maze, crafting a code solution for a given problem rarely has a single best solution. Each of us tackles a problem differently because we have different experience, opinions, and tendencies.

There is nothing wrong with inconsistencies from developer to developer. It is often our ability to each look at a problem differently that makes our teams stronger. But when it comes to writing those solutions and actually committing something into our design system, there is no desire, or need, for our code to reflect all of those differences.

Even if we could get every developer solving problems in the same way, there is no guarantee that it is the best possible code for the rest of the system. They might be creating a beautiful, well-crafted Bootstrap theme when the project actually called for something much more custom.

The code pillar is here to help us have conversations about the code quality of our HTML, CSS, and JavaScript. It is here to help us define how we are going to write our classes, build our functions, and mark up our interfaces.

The following chapters are nowhere near exhaustive. As a frontend architect, it is your job to continually be exploring and evaluating new techniques, platforms, methodologies, and ...