Considerations: Component vs Utility-Based CSS Design Systems

When starting a greenfield project or updating your existing application to a new CSS design system, the most prominent options many projects start with consist of the following: an existing utility-based framework, design a custom utility-based framework, or build a component-based system. This article focuses on the basic, core level differences for those who are unsure where to start. Let’s go through the details on how each works and their best fits.

What is a Utility-Based Framework?

Utility-based means that when implementing designs, you use predefined classes to set font sizes, padding, margins, colors, etc on each individual item to create a custom element from the available options. The major perk of this is being able to customize elements independently, one at a time. Each element can be altered slightly without writing additional styles.

Existing Utility-Based Frameworks

Existing frameworks may speed up the process and cost less, but will often include excess code that may impact load times and complicate certain design decisions due to opinionated markup. Using a framework can be beneficial in that it allows for rapid prototyping without the same overhead as custom implementations. These frameworks are great at getting things off the ground quickly but are often replaced after an application grows beyond the framework’s needs. Being a popular approach, there are several options available such as Bootstrap, Foundation, Semantic UI, and Skeleton.

Using Bootstrap as an example, here’s some basic markup to show what an element’s class structure might look like when using an existing utility-based framework. This will generate a padded div with a light gray background, black text, a dark gray border, and rounded corners.

<div class="p-3 bg-light text-dark border-secondary rounded">
  Lorem Ipsum Dolor Sit Amet
</div>

Custom Utility-Based Frameworks

If your design is looking to do something more adventurous, needs strict limitations due to branding constraints, or needs to focus heavily on performance due to high traffic, a custom design system might be preferable. By creating a custom design system, spacing, colors, fonts, and any other details you choose can be defined with no additional options beyond what is required to complete your vision. The restrained markup means the page can load quickly, and the development team will have limited opportunities to break branding guidelines. Littlelines often takes this approach when building applications with custom designs and strict guidelines.

A custom utility framework can define custom class structures that make more sense to your team, or match your branding guidelines more accurately. Here’s an example of a custom framework we’ve generated to do the same as the panel example above.

<div class="padding-all-3 background-gray-light gray-dark border-all-1 border-dark-gray border-radius-3">
  Lorem Ipsum Dolor Sit Amet
</div>

This example is more verbose but follows a standard naming convention our team prefers. It uses predefined padding options rather than arbitraty patterns, can use custom-named colors that are unified with the application’s branding guidelines, and doesn’t require overwriting existing styles like in a predefined framework. (Overwriting styles will often result in slower load times as the browser renders each style definition consecutively, even if you have overwritten it.)

Component-Based Systems

While utility-based options can function in any type of project, sometimes repetitive layouts can be best implemented with components: reusable, segmented blocks of predefined elements. Each element can have predefined styles and variations which limit how branding can be implemented and favors a single class per element rather than a series of utility classes to style it.

An example of the clarity and cleanliness in component based frameworks can be showcased with this minimal markup representing the same panel as before.

<div class="panel">
  Lorem Ipsum Dolor Sit Amet
</div>

This markup is simple, but uses styles written explicitly for this one use-case. It means that when an element is used, it’s always going to look a certain way, or require additional stylesheet changes. This results in a clear use of the branded UI, and can be used to make far reaching changes to each instance of the component when updates are required. Variations can be added using methods like BEM to separate the versions of a component if needed. If we need a version with a red background and white text, we could create a modifier that would appear as follows:

<div class="panel panel--alert">
  Lorem Ipsum Dolor Sit Amet
</div>

Single Page Apps

Sometimes your development environment can lend to which design system will be best suited. For example, single page app frameworks such as Vue.js or React can benefit from custom designs systems using a component-based approach. This process involves building out individual parts of the site such as sidebars, menus, buttons, etc where the code for each item is self-contained. Doing this allows styles to only be pulled in when the specific element is rendered onto the page, creating a separation of styles per element with semantic naming of classes. After this point, a developer only needs to import the component, and it will be styled exactly as it should be.

An example of a self contained component would be used in a method like this:

<panel>
  Lorem Ipsum Dolor Sit Amet
</panel>

This component could contain all of the logic, styles, and markup required to display the elements exactly as intended each time, ensuring consistency.

TL:DR

Existing utility-based frameworks are best for quick, cheap development such as rapid prototyping or MVPs (Minimum Viable Product).
Custom utility-based frameworks require a little more budget, but can give better performance and can allow a site to represent your brand with custom designed utility classes.
Component-based systems have cleaner and more customized markup and benefit greatly in single page apps.

Side Note: These are general guidelines we follow when making the decision which approach to use, but any of the above options are viable for your project. In many cases, whichever approach you’re most familiar with will be the most efficient and cost-effective but long term maintenance will be impacted by the complexity and flexibility of the decision you choose, so be sure to plan ahead.