Beyond Bootstrap –moving from UI toolkit to component library
Tags: ui, componentlibraries, react, frontend
Published: 2017-11-08 03:44:08

---
title: "Beyond Bootstrap –moving from UI toolkit to component library"
published: true
tags: UI,component-libraries,react,front-end
canonical_url: https://blog.hichroma.com/beyond-bootstrap-moving-from-ui-toolkit-to-component-library-f0a34f05e98b
---

![](https://cdn-images-1.medium.com/max/986/1*UMdYa8Cvv7nncxtz6CwB-w.jpeg)<figcaption>Image: <a href="http://www.spatialagency.net/database/haus-rucker-co">Haus-Rucker-Co</a></figcaption>

The first factory predates the industrial revolution by hundreds of years. [Venice’s Arsenal](https://en.wikipedia.org/wiki/Venetian_Arsenal) pioneered assembling naval ships out of standardized parts. Engineers of the time discovered that it was quicker and easier to _assemble_ complex things from their constituent parts rather than _build_ them from scratch. Today, we’re seeing this idea of [prefabrication](https://blog.hichroma.com/prefabricated-components-2932bfc992ba) and assembly take hold in a different sphere of engineering: building user interfaces.

User interfaces are increasingly assembled from standardized parts. **UI toolkits** like [Bootstrap](https://getbootstrap.com) were among the first to provide a generic collection of parts for web UIs. These toolkits enabled developers to easily find and apply patterns in their&nbsp;apps.

Companies too recognized the value of having their own UI toolkit. They created **living styleguides** to match the look and feel of their brands. However, building a styleguide requires significant resources so only larger teams tended to invest in&nbsp;them.

A key change in the industry has come with the advent of **UI**  **components** â€Š–â€Šbuilding blocks of user interface akin to Legos. Components simplify building custom UI toolkits because they encapsulate design patterns in modular standardized units.

This paradigm shift allows teams of any size to create “ **component libraries**  tailored to their exact needs and brand. Today, I’ll walk through how we got here and the process of creating your own component library.

## User interface assembly

Frontend developers build the same user interfaces over and over. There aren’t many _functional_ differences between them. You’ll usually find the standard combination of header, sidebar, lists, and&nbsp;forms.

![](https://cdn-images-1.medium.com/max/600/1*HUUqhC5phoYZFWR4n8VDWg.gif)

Throughout history people have found that it’s more productive if people assemble new products from existing parts. User interface engineering is no exception. Composing new views out of existing UI parts is faster than building them from the ground&nbsp;up.

At first these patterns took the form of ad hoc code snippets. They lived in text files stashed somewhere on developers’ machines (pre-Github). Albeit not very shareable, these bits of UI code had enormous utility to the frontend developer.

## Bootstrap and UI&nbsp;toolkits

Bootstrap came along and consolidated these pieces of UI code into a single well-documented collection. The key idea of UI toolkits was to provide an inventory of generic/universal **design patterns** (with accompanying code).

![](https://cdn-images-1.medium.com/max/1024/1*KG74W9pMhj29IfkNoCZAwA.jpeg)<figcaption>Bootstrap’s designÂ patterns</figcaption>

At the time, the workflow was revolutionary in its simplicity. You copy–pasted markup and got workable user interfaces. UI toolkits made it trivial to scaffold simple sites and line-of-business apps.

The concept of UI toolkits had an enormous impact on design and development. It proved that designers could ensure user interface consistency throughout the development process. It also highlighted how easy it could be to create UIs using a toolkit to developers.

## Living styleguides

Living styleguides are organization-specific UI toolkits. Teams saw the inherent value in UI toolkits, but often had specific look and feel requirements. They couldn’t just adopt Bootstrap, Foundation, or Semantic.

The classic downside of something like Bootstrap is that you must adhere to its prescribed idioms and styles. Sites that rely on popular toolkits tend to look the same. You can probably see why this isn’t ideal for a company looking to stand out in the&nbsp;market.

Like Bootstrap, living styleguides provided a similar inventory of design patterns along with code, but these patterns reflected the particulars of company branding and&nbsp;design.

[![](https://cdn-images-1.medium.com/max/1024/1*pfc0_uCd1d1DpdK3-EtUXg.png)](https://walmartlabs.github.io/web-style-guide/#buttons)

At the scale of [Yelp](https://www.yelp.com/styleguide#buttons), [Walmart](https://walmartlabs.github.io/web-style-guide/#buttons) or the [US government](http://codeforamerica.clearleft.com/), reusing existing design patterns yielded massive efficiency gains. Living styleguides made it easy for big companies to create a consistent look and feel _across_ their web properties.

However, creating a living styleguide is a significant undertakingâ€Š–â€Šoften requiring coordination from the top down. There are countless UI permutations to design, build, and maintain accompanied by the daunting task of getting buy-in from everyone on the team. Realistically, the luxury of living styleguides was reserved only for large&nbsp;teams.

## Component libraries

Component libraries are a pragmatic way for teams –large _and_ small– to get the ease of Bootstrap, the customizability of living styleguides, and the flexibility of modern view layer technology.

The widespread adoption of view layers like React, Angular, and Vue compel teams to decompose UIs into simple components. These components serve as the building blocks of apps; the collection of components is the basis of a component library.

![](https://cdn-images-1.medium.com/max/800/1*UsivbxsBxiiltJ2dYjniqA.gif)<figcaption>A self-contained <a href="http://airbnb.io/react-dates/">DatePicker</a> component</figcaption>

### Components: self-contained functionality

As a construct, components are more powerful _and_ easier to use abstractions than raw code. They are self-contained pieces of functionality that have well-defined inputs and&nbsp;outputs.

Self-containment encourages developers to scope functionality, markup, and styling(this area is [rapidly evolving](https://medium.com/seek-blog/a-unified-styling-language-d0c208de2660)) at the component-level. No need to rely on toolkit-level JavaScript or stylesheets, with UI components all of this can be encapsulated in the component.

### Small teams can build component libraries

The focus on components –the user interface equivalent to Legos– makes it easy for small teams and individuals to start building their own inventory of custom design patterns **piecemeal**. Since you progressively accumulate UI components, the startup cost of a component library turns out to be less than building a living styleguide (which often requires much forethought and planning).

In addition, flexibility is inherent to component libraries. Each component can be added, updated, or replaced without affecting the integrity of the library. This means that you’re not constrained to one UI toolkit at a time, you can mix, match, and customize components from around the web as&nbsp;needed.

## How do I get&nbsp;started?

Whether you have an existing app with components or are building one anew, starting to accrue the benefits of a component library is easy. Since you’re able to add components individually and the tools to build libraries tend to be _development-only_ by default, the cost to try a component library is close to nil. Let’s see how to get started in&nbsp;4-steps.

#### 1. Get a place to “store your components. 
Components are often buried inside apps. This isn’t ideal because people have to scour through directories and screens to see components in action. What you want is a central place to catalog and visualize your components. You can find these library-like features in a [component explorer](https://blog.hichroma.com/the-crucial-tool-for-modern-frontend-engineers-fb849b06187a).

![](https://cdn-images-1.medium.com/max/992/1*jTl0e2sNMfJQX3znZULmEA.png)

##### Component explorers

- **React:** [Storybook](https://github.com/storybooks/storybook), [Cosmos](https://github.com/react-cosmos/react-cosmos), [Carte Blanche](https://github.com/carteb/carte-blanche), [Styleguidist](https://react-styleguidist.js.org/)
- **Angular:** [UI Storybook](https://github.com/ui-storybook/sb), [Playground](http://www.angularplayground.it/)
- **Vue:** [Vue&nbsp;play](https://github.com/vue-play/vue-play)
- **Ember:** [Freestyle](https://chrislopresto.github.io/ember-freestyle/)
- **Clojure:** [Devcards](https://github.com/bhauman/devcards)
- **Meteor:** [Chromatic](https://github.com/meteor/chromatic/)

#### 2. Index existing components
 Once you get a component explorer, it’s time to index your app’s existing components so they can be&nbsp;found.

![](https://cdn-images-1.medium.com/max/800/1*zmoiFngqTlycnY7k4IK-VQ.gif)

Start by importing the component explorer tool at the top of your component file (the exact syntax varies between component explorersâ€Š–â€ŠI’m simplifying for readability).

`import { specsOf } from â€˜@component-explorer/explorer’;`

Next, write your first “test states for that component as specs. For instance a Toggle component might have default and active&nbsp;state.

```
specsOf(â€˜Toggle’) 
  .add(â€˜default’, () => <Toggle active={false} />) 
  .add(â€˜active’, () => <Toggle active={true} />)
```

Then checkout the component in action via the component explorer. Repeat this process to index other components and grow your&nbsp;library.

![](https://cdn-images-1.medium.com/max/900/1*Aw8z6q9HDZVQRNWcq8GK4A.gif)<figcaption>A toggle component in Storybook</figcaption>

#### 3. Browse thousands of open source components 
There are plenty of readymade UI components available from organizations like [Salesforce](https://medium.com/u/e7b0f31549dd), [AirbnbEng](https://medium.com/u/ebe93072cafd), and [Google](https://medium.com/u/991272e72e68). Familiar UI toolkits like Bootstrap and Foundation have also been converted to UI components. For complex components like graphs, I suggest browsing what is already available before building something from&nbsp;scratch.



#### 4. Add open source components to your library.
Once you’ve found something you like, it’s time to put it in the component explorer (as we did in step 2). This gives you an isolated playground to tweak the readymade component before integrating it into your&nbsp;app.

Let’s simulate the process of adding an example LineGraph component to the&nbsp;library.

Installing via NPM: `npm install linegraph`

Create a new file to import the component, the component explorer, and record the test states as&nbsp;specs.

```
import { specsOf } from â€˜@component-explorer/explorer’;
import LineGraph from 'linegraph';
```

Add a few test states to adjust the look and feel in isolation with your component explorer. Here’s how the component would look with a default and active&nbsp;state:

```
specsOf('LineGraph')  
  .add('Default', () => 
    <LineGraph data={latencies.map(latency => ({    
      latency,
      count: 5000 + Math.random() * 15000,  
  }))} />)

.add('Active', () => 
    <LineGraph active={true} data={latencies.map(latency => ({    
      latency,
      count: 5000 + Math.random() * 15000,  
  }))} />)
```

![](https://cdn-images-1.medium.com/max/980/1*oCsBsPX1QtvQPSWKaBnrLQ.gif)

Once you’ve adjusted the specs to match your needs, it’s simple to add the component wherever you need it in your app and use similar specs to achieve the intended appearance.

![](https://cdn-images-1.medium.com/max/800/1*DTzw9Ci4Q2_aM_gWNzwtXw.gif)

## Beyond Bootstrap

Bootstrap pioneered the use of readymade user interfaces. People could pull interface elements off the shelf to rapidly build UIs. However, it required adherence to prescribed idioms and&nbsp;styles.

Living styleguides allowed organizations to offer the same rapid development experience as Bootstrap with a custom look and feel. The challenge was that these styleguides required significant effort.

A component library is a practical middle ground that enables rapid development and customization without needing much in the form of organizational momentum. Here at Chroma, we are big proponents of component libraries because they tend to guide teams into reuse and UI consistency without being authoritarian about&nbsp;it.

<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2F3f1921%3Fas_embed%3Dtrue&amp;url=https%3A%2F%2Fupscri.be%2F3f1921%2F&amp;image=https%3A%2F%2Fupscri.be%2Fmedia%2Fform.jpg&amp;key=d04bfffea46d4aeda930ec88cc64b87c&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0" scrolling="no"><a href="https://medium.com/media/c066cf834200d80e25b62a6de730a4a6/href">https://medium.com/media/c066cf834200d80e25b62a6de730a4a6/href</a></iframe>

**Learn more about UI components:**  
- [Why you should build UI components in isolation&nbsp;Â»](https://blog.hichroma.com/prefabricated-components-2932bfc992ba)  
- [5-step guide to creating modular frontends&nbsp;Â»](https://blog.hichroma.com/ui-component-playbook-fd3022d00590)

* * *


_This post was originally published on [blog.hichroma.com](https://blog.hichroma.com/beyond-bootstrap-moving-from-ui-toolkit-to-component-library-f0a34f05e98b)_