If you have been following web development news this past year, you will have noticed, and hopefully read about, the outbreak of Atomic Design and its impact on many frontend developers’ building processes.
Originally, I had simply thought of Atomic Design as a design system that could be used to prototype websites or just structure HTML components in a better way. However, I am here to tell you there is more. Much more.
But first, an overview! Or, if you already know what Atomic Design is, skip down.
Atomic Design
Atomic Design can be broken down into five simple categories.
Atoms
Atoms are the smallest part of any website or app. You can consider it the simplest HTML elements and pieces such as <p>, <button>, fonts, or colors. Atoms are the smallest piece of your website and by themselves are not of much use.
Molecules
Molecules, much like in real life, are more complex structures made of a combination of atoms. For example, in the web, you can consider a molecule something like a search box with a submit button and input field or an image with a text caption underneath.
Organisms
Organisms are a grouping of molecules, atoms, or a combination of the two. It is easiest to think of organisms at their simplest form: a unique entity such as a web form or login box. The goal of organisms is to create reusable, modular components that if necessary can stand alone but are more commonly placed together for the next level, templates.
Templates
You will most commonly see templates made of multiple organisms to form a generic structure and flow. They will look like what you expect a “page” to look like, but they are just examples without real content.
Pages
Pages take templates a step further by using content that the end user will see for a specific page. You can consider pages to be the end deliverable to clients or the end user who is visiting your website or application.
For a more in-depth read on Atomic Design, go check out Brad Frost’s article, or take a look at the Pattern Lab.
This Should Feel Familiar
The principles of Atomic Design should feel eerily familiar to anyone who has looked into [Object-Oriented Programming](https://www.oodesign.com/) (OOP). Each system is built on the concept of modular components that abstract out the bigger concepts and ideas. You can go so far as to say that for each of the five levels of Atomic Design, OOP has a counterpart.
Atoms as Variables
Molecules as Functions
Organisms as Classes
Templates as Libraries
Pages as Programs
Although some of these terms may be foreign or seem overbearing, with your knowledge of web development and Atomic Design, you should begin to see a pattern: modular, composable components.
However, the most exciting thing about these similarities is the years of experience and knowledge from OOP principles and how you can apply them to frontend web development. With a rich history of practices, programming patterns, and working applications, you can use the mantra of “modular, composable components” to create your own styleguide for development.
It is important to remember that similarities between Atomic Design and OOP do not necessarily just equate to modularity, but you can also inherit their testability. Until recently, this seemed like a very odd thing to say. Why would you ever be testing little chunks of HTML? However, have you ever tried to add a third-party plugin and had it not work due to some JS or CSS conflict with your code? If you follow a modular flow of code, our little bits will look and act just like these third-party code snippets. With tests, you can prevent the pain of debugging errors and publish your code for others to use without a flurry of issues popping up in your inbox. But how do you test HTML code and small interaction pieces? Web components.
Web Components
As a whole, web components are broken into four unique parts:
Custom elements
HTML imports
Templates
Shadow DOM
These parts all work together to create a piece of code that you can use in your current website as a custom element or in other custom web components. You can treat web components as building blocks that can help extend Atomic Design. As abstract elements, you can create web components that can reflect any level of Atomic Design.
You can create web components that are molecules, such as , or organisms, such as , that inherit other unique molecules. The possibilities are limitless!
Encapsulation
One of the unique parts about web components is that their modularity does not seep into whatever imports it. In programming, we often use the word encapsulation, which simply means a component contains its own dependencies.
I like to refer to encapsulation as tupperware. You can pack a lot of unique meals into separate identical tupperware containers, but if you want to add salt to one or eat one, it isn’t a big deal. Also, you can keep food sealed and safe from any outsiders’ grubby hands. And the best part is that none of the other tupperware containers will be affected if you get hungry at 1 AM.
What this means for us as developers is that our web components can be used anywhere without any fear of them affecting our current websites or our websites affecting them. They can be safely reused on any of our websites with their own styles and logic, which should excite you—if they work!
Which brings me to testing.
Test all the Things!
Now that you have unique, modular pieces of code, you write tests for them, right? The correct answer is yes.
Testing is vital to ensuring your code works. Without tests, you cannot say with absolute confidence that your code will work when it is deployed. As developers, it is vital to stand behind your code and know it will work before shipping it. Not testing your code is like playing Russian Roulette with your users. One of them will be using IE7. Oh, and they will find that code that doesn’t quite work for their awful browser. Testing. You should be doing it.
Don’t let excuses get in the way. There are a lot of different testing frameworks and resources that you can use to test your web components. For starters, check out Jasmine or Mocha. They both have great communities and documentation to get you up and testing quickly! Also, if you are using Polymer, take a look at Google’s web components Github and how they are testing their web components. Some of Google’s tests are only 20 lines, with whitespace and comments. You can do it too!
If you have questions about testing your frontend code or where to start, check out Rob Tarr and Ryan Cromwell’s slide deck on Frontend Testing, or you can also contact Build Right to find out how to bring this workshop to your company.
Re-invent the wheel! Wait, what?
However, before you go out and get too crazy with web components, let’s take a step back and remember what has already been given to us. Under no circumstance should you be re-implementing elements that already exist as standard (list elements, paragraph elements, bold, italic, and the like). These elements are already implemented, and it would be irresponsible to ignore accessibility and the semantic context these elements already give.
Also, with every web component you create and extend, there will be a little overhead for instantiation and there may be a small hit on performance while browsers continue to implement web components as standard (looking at you, Safari and IE). In order to get them to work, there are many libraries out there to help polyfill browsers who are a bit behind the curve (Polymer, X-Tag, and more).
With that caveat out of the way, dream on! Go build the web!
