Atomic Design, or Functional Design as it is also referenced, is a bit of a weird beast. On one hand, it is a programmatic shorthand feature that allow you to use short code in development that then render CSS based on that, but it also a philosophy of sorts on how to organize CSS. A philosophy that very much resemble the inline-css era of old.
The problem statement
I think this statement says a lot on how ACSS and to some degree Atomic Design itself see the world of CSS. Anyone working with wild or free CSS development can certainly recognize some of these pain points. This is not uncommon in scenarios where many developers work in the same project or you have to work on top of a not so well-designed product.
The question is, though, how many still work in that way and why?
In a scenario where you have a defined design pattern, which should be the norm these days, this is rarely an issue. Regardless if you do atomic design or component design, your styles should be easy to maintain and define. Despite this I still see a lot of JS developers adopt inline styling and duplication of CSS in components. This is more common in libraries like React and Angular, I feel (personal experience, no real numbers to support that).
So it is not surprising to see a rise in areas like Atomic Design or ACSS since that help bridge the gap in skill levels some JS developers have and the inherent despise we have to spend more time than we have to on things we don't really enjoy doing. Not to mention, there are some benefits that should not be overlooked.
ACSS - Atomic Design as a preprocessor
ACSS is a preprocessor that will transform inline HTML variables and create CSS from it. It has a fairly simple syntax and it works by looping though the HTML and scrape up the variables and then make a CSS file from what it finds. In many ways, this is similar to inline CSS, but you would get a static CSS file instead of just printing it out in a style tag.
If we borrow an example from the excellent CSS-Tricks site that I highly recommend you check out, then here is a snippet of code where we declare some classes and input a variable to each.
<!-- Programmatic Atomic CSS Example -->
<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>
The output from this would then generate the following CSS:
.Bgc\(#0280ae\) { background-color: #0280ae; }
.C\(#fff\) { color: #fff; }
.P\(20px\) { padding: 20px; }
This may seem quite useless compared to a well-defined CSS with variables declared that I could just input, but you could use both of course and use this to override in certain situations. Similar to how you would use inline styling.
The biggest benefit of this however is that the CSS generated would be as small as you could make it. This is because the CSS would be based only on what can be found in the HTML. This can be useful for development in for example Angular and React, where I assume this is mostly used.
In situations where you have classes reused over many components, like this website however, that would not really be as beneficial as having multiple CSS files is never a good thing and you would see duplication of classes. This is of course if you generate the CSS on a modular basis, but not if you render it globally on load somehow.
Overall, I do not see any need for me working with sites like Invision Community and I feel it would not really work well in an atomic design situation with defined styles in both the UI and the HTML/CSS that is reused across components.
I may be completely wrong about that, as I have not tried it and if so, sign off in the comments to tell me I am wrong 🙂
Atomic Design as a Philosophy
The idea of Atomic CSS is simple and, to be honest, not very new. The idea is to create single attribute classes and then stuff the HTML with them. Kind of like you would do using Inline styling, but with a global definition of the styles. It would look something like this.
/* naming utility classes */
.relative {
position: relative;
}
.mt10 {
margin-top: 10px;
}
.pb10 {
padding-bottom: 10px;
}
I say that this is nothing new because this has been around since before inline styling even existed. One reason it is not widely used is because it makes the HTML cluttered and hard to read. It is also a bit annoying to work with compared to having well-defined CSS classes as you will have a ton of attribute shortcuts basically rather than a library of styles.
If you are used to working with frameworks like bootstrap, then you are already familiar with the concept, since those frameworks also have libraries of smaller styles that you can mix and match. Atomic CSS is much smaller however and rather than having for example a flexbox class that have the standard values you use all over the site you have to build those up with a set of classes inline in the HTML.
Is it a terrible idea?
Atomic design as a concept can be traced back to October 2013 and an article written by Thierry Koblenz. It has since evolved and you will often see it in reference from the new breed of JS developers that work in frameworks like React and Angular. While it may be a bit unfair to say that these new JS developers do not have that same deep understanding of CSS as the "regular" front end developers, I do see this distinction growing.
For the JS developers however, this is pretty useful as they can focus on function rather than form. You have probably seen the mess that sometimes happen when JS developers mix inline styling, component specific styling and global styling. It is as bad as having multiple novis CSS developers trying to use EM when they do not control the output containers...
I hear some arguments that this makes it easier to avoid specificity issues, but I do not agree with that. If you control your code, then you are a pretty bad developer if you can't handle your classes properly. It all comes down to planning and setting structures after all, unless you are just playing around like I do on this site.
I digress though and to answer the question if this is a terrible idea I think there are use cases for when this can be useful. Since that article in 2013 however, I think those use cases are less now, especially with the introduction of CSS variables. I do however think there is a very good case for using this same idea for defining variables and to keep your classes small as a philosophy.
I do think there are certain scenarios where it is a good idea to use the concept of Atomic design, and that is for overrides. Things like fonts, colors and spacing can be useful to sometimes just make a small adjustment rather than building new components.
Also, if you generate your content at runtime on the server, there are benefits to this since you can combine it with CSS-in-JS to dynamically generate very small CSS files. I guess this is why React and Angular developers are liking this way to organize your CSS classes. You can still do this working with regular CSS, but the files will be bigger since you are bound to have duplicate attributes in your classes.
So it is not a terrible idea, but it comes with some issues.
Allow me to explain...
My Thoughts
While there are benefits in some cases, there are some negatives as well. The biggest issue for me is that while we reduce the CSS, we instead increase the size of the HTML. The HTML also becomes much more cluttered and harder to read because unlike CSS where we can group classes, or even split them on multiple files, HTML will just be one big garbled mess.
Consistency is also an issue because the idea of recreate clusters of classes to achieve the components is done manually every time, then you will see consistency go out the window. We see this all the time in wild or free CSS, where pretty much every component have its own class styles uniquely. This is especially problematic if you have JS developers that are not very good at using CSS and you try to set up a design library.
At the end of the day however, front-end developers are flexible and resourceful people. All of these potential pitfalls can be managed and if Atomic CSS works for you and those that you collaborate with, then go for it. Just don't make the decision just in the development team as you need to work well with both Design and Test so they should have a say as well. Also, your way of working must work across teams, so don't start using Atomic CSS if you at any time will have other teams working in the code as well.
You know all that of course, but it is something that you can never repeat too many times.
Do you use Atomic Design today?
If you do, what benefits and pitfalls have you uncovered?
