Working with the Four Pillars

Throughout the rest of this book, we will discuss what I call the four pillars of frontend architecture. These four groups of topics, technologies, and practices are the foundation of a scalable and sustainable design system. They set up a series of discussions that need to be had about the frontend of any new project. These conversations will help to set expectations in code quality, the time and effort needed to finish each user story, and the workflow process that will get all of this done in a timely manner.

These pillars in no way prescribe the only way to do something, or even the best way to do something. Each decision needs to be made in the context of the project that you are in. Sometimes the decision will be to not do anything! Projects of smaller scale, or those that are transient in nature, might not require the same level of foundation as a Fortune 500, customer-facing property meant to last several years.

Do not take the upcoming chapters as a list of topics to master. To be a frontend architect is to be in a state of constant learning. This constant state of learning is what defines us. Our inch-deep, mile-wide understanding of the entire frontend development space is what allows us to be champions for new technologies and methodologies.

One of our strongest skills is that we can spend an hour with a new framework or Gulp plug-in, and identify its strengths and weaknesses and possible use in our project. So if you find yourself overwhelmed by the sheer number of technologies and topics in the rest of this book, just remember that none of us are masters of all of these. I personally range from expert in several of them, competent at many of them, and completely new to others.

So, enough dancing around these pillars, let’s dive into them and discuss the significance of each.

The Pillars

The code pillar

When it comes down to it, every website can be broken down into a bunch of text files and media assets. When we start to look at the sheer number of lines of code produced in the making of a website, it is incredibly important that we set expectations for the code that is written and the assets we create.

In this pillar, we will focus on how to approach the HTML, CSS, and JavaScript of a design system.

The process pillar

As we are miles away from a workflow of FTPing into a server, editing a file, and hitting Save, it is important to start thinking about tools and processes that will create an efficient and error-proof workflow. Our build processes continue to grow in complexity, as do the tools that we use to create them. These tools bring incredible gains in productivity, efficiency, and consistency, as well as the risk of over-engineering and unnecessary abstraction.

Just as our workflows have evolved, so has the way we work. We are no longer spending our time making the CMS markup “look like” some Photoshop comp. As we move to designing in the browser, and creating responsive HTML prototypes, we are often writing all of the HTML and the CSS before the feature is even implemented in the CMS. This incredible role reversal needs to be supported by a change in development process.

The testing pillar

In order to create a scalable and sustainable design system, we need to ensure that any code we wrote yesterday isn’t devalued by the code we write today. Our code isn’t written in a vacuum, but rather is part of a much larger system. Creating a plan for sufficient test coverage will ensure that yesterday’s code continues to provide the value it did on the day we wrote it.

In this pillar, we will take a look at three different methods for testing our sites. Sometimes, depending on the team size, these tests will be split between frontend, backend, and ops, but a solid understanding of each of them will be valuable when you’re communicating with those other teams.

The documentation pillar

It seems that few see the value of spending time on documentation until a key member of the team is about to leave, and then it’s “stop everything and document all the things.” As a frontend architect, you will be a champion for documentation that is written at the same time as the process or artifact being developed.

This pillar will look at those various types of documentation your team might need to write, the tools used to make publication easier, and the types of end users that will ingest the content.