Using CSS Design Systems with Component Based Architectures
By: Nikhil Sikka
Tags: Web Development, Atomic Design, Styling Tips, CSS, Component Based Design

Some companies pride themselves on their super scalable code structure and the awesome technologies they use. Some of them are right, some of them forget CSS, which can make developers pull their hair out.

We’ve all been there

Now, I am not saying they don’t know how to do it, but, in most of the teams, the developers pay very less attention to the styling of the entire application. This isn’t a good thing as, when the company grows, you have more users joining in the party and we all know it by now how much the users love a good design and experience. (Ask Orkut, how they lost the social media war because of a lot of reasons including a big one in the form of Visual Appeal and User Friendliness. )

So What to do?

Building features is fun and really important, not gonna deny that, especially in the beginning. But, when the product matures up the application needs to look better and feel better. If you’ve heard of the Maslow’s Hierarchy of needs, you’ll know in order for humans to be satisfied, they must get all of their needs fulfilled. (i.e ultimate gratification!) However, the most basic needs, like food, water, sleep etc needs to be fulfilled before they can go about buying the new Mac Pro. (Seriously, why will someone pay 6k for a cheese grater?). And the same can actually be applied on to the design of any application out there (it kind of already is).

Developers first build the raw features, not even remotely giving a crap about building that sexy looking primary button with those enthralling box-shadows that even Google would be proud of…. and for good reason. Initially, what's more important is to build the feature that allows the user to click the button and make the action. Cause if there are no users, who are gonna be looking at that button anyway? The visual appeal kicks in as and when the product matures up. But then, when it does, the developers will have a huge problem on their hands, as almost all of us are guilty of writing a horribly structured CSS code, initially convincing ourselves — “I’m gonna refactor this monstrosity later”. TL;DR — never happens, or at least not how you expect it to be.

There are better ways than spamming your CSS with !important

So what am I getting at?

Well, ever since the early 2010s, when a host of JS frameworks started popping up everywhere, people started thinking in a bit more in a Component Based Architecture (CBA) style as compared to the traditional Model-View-Controller (MVC). Which isn’t actually bad to begin with. It encourages reusability, forcing developers to write DRY code along with single-responsibility. But, the problem is even though the features got the attention they wanted, the little guy (CSS) and the problems related to it got ignored more or less.

Because of that, there is a huge, massive pile of CSS that no one wants to touch, cause if they do, it might end up doing what Barry Allen did to the timeline (#Flashpoint). Often, it leads to bugs everywhere in the rest of the application and sometimes it is so chaotic that nothing changes because one style is being overridden by another which is then being overridden by one more which is being overridden by a third party library.

What happens you change the colour from Purple to Red in a CSS monolith.

If only we could structure our app in a way that when the designer wants the developer to change the height of the primary button on every page by 2px, the developer doesn’t end up spending doing the same until his kid graduates.

Well, we can actually, there are now hosts of frameworks/guidelines/design-systems (whatever fits) out there like ITCC, BEM, SMACSS, Atomic Design etc. They all have their pros/cons and there are always tradeoffs when you’re dealing with options in the software world. No tech is perfect and every tech has its purpose and use case. But, if we talk about the ability to implement design changes quickly and easily, one of these things stand out a lot — Atomic Design.

Now, In no way I’m saying this is the best, but when it comes to making widespread changes quickly this one really takes the cake (if implemented correctly)

My Pick — Atomic Design + OOCSS

I’m sure you must have heard of this system a lot by now, if not just give this a read as I won't dwell deeper into explaining this much here.

Now, along with your choice of JS framework, this design pattern works really well, especially if you’re working in a Component Based Architecture as you don’t really have to think so much into dividing your CSS initially, as you think about the React component while building a feature, and you divide them into single purpose and small components so its scalable, you just need to do the exact same for the CSS you write for those components except, you use Atomic Design to set up the folder structure and division reasoning.

In Atomic Design, It goes without saying smallest are Atoms and at times Molecules, which in turn come together to create Organisms, which are used to create the various Templates and Pages of our Application. But, while doing that, you create a unidirectional cascading effect of styles which allows you to change the button height your designer asked for in minutes. (Who doesn’t want that?).

So, if you want to change the box-shadow of one specific button inside a huge page created using multiple Templates created using this system, all you now need to do is change it in ONE Atom in just ONE place and boom.

Now, Atomic Design tells you how to split up and structure your Styles to have a sturdy and scalable system in place. But doesn’t stop you from using any naming convention you might prefer. I would personally go for the OOCSS (Object Oriented CSS) along with Atomic Design as it really syncs up well with it.

The Pros?

It goes without saying, every design system solves one or the other problem. But Atomic Design specifically, really helps in increasing the speed of changes in more complex apps the further the code grows. It’s not something you’ll start appreciating from the get-go, but I can assure you it’ll be super satisfying when you are able to change tiniest of details in minutes and see it be properly changed everywhere it's used.

It helps in reducing the time taken to do simple tasks. Removes Inconsistencies and redundancies in CSS due to the code being reused. Reduces the risk of screwing up other things when changing something small, as it happens in those big spaghetti stylesheets we see everywhere. You end up getting a really clean component library of your own that can then be shared across projects and teams really easily.

Any Cons?

Well, as I mentioned before, every technology you use has its pros/cons and tradeoffs depending upon the purpose of the use and situation and the people using it.

Breaking up an app into smaller bits may be overkill for something as simple as a static portfolio website. It requires a LOT (and I mean LOT) of discipline in the team that is working with it. It requires someone who can actually take charge and call shots when abstracting requirements and executing the implementation of the same. Any new developers will need to buy into the philosophies and require additional on-boarding so they can contribute properly.

In the end, I feel it’s always about comfort and adaptability along with the skillset of the team. We still don’t, unfortunately, have a one-system-fits-all solution, so we all need to find the one that fits us the best. It’s a long post, I realise that. But I’m hoping it helps at-least one more person out there!