|View this newsletter on the web.
[Robin]: Someone emailed me the other day out of the blue and noticed an odd pattern: apparently whenever I write about just about anything design systems related or about front-end development, the conversation always comes back to my frustrations with Bootstrap. I’m constantly refactoring it, removing it, tidying it up.
So: why’s that?
Well, I think Bootstrap is an example of a remarkably good tool that’s often misused. And the reason why is because when folks start building an app they often think of CSS as something that’s annoying, something that shouldn’t be built from scratch so they turn to a library like Bootstrap. They don’t want to have to build a carousel or a button or an anything for the millionth time, they just want to copy and paste HTML and CSS together to make it work.
The problem with this is that if left untended, Bootstrap can become an example of radioactive code.
The last three projects I’ve worked on all started with Bootstrap to provide the foundations for things — they’d start by loading Bootstrap via a CDN in the head of the document:
<head> <link href="https://email@example.com/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-eOJMYsd53ii+scO/bJGFsiCZc+5NDVN2yr8+0RDqr0Ql0h+rP48ckxlpbzKgwra6" crossorigin="anonymous"> </head>
This is bad for a whole bunch of performance reasons so eventually folks would start using it as a dependency in node. They would
npm install bootstrap and badda bing badda boom, you now have all the CSS you’ll ever need.
The problem here is that Bootstrap contains so much stuff that you don’t need 95% of it. You’ll need the reset, the normalize styles but the dozens and dozens of component styles you won’t need or ever use. They’ll just get in the way and slow you down.
But not only are you asking users to download data but it will make for a worse developer experience, too. That’s because folks on most teams will start to componentize their front-end code and instead of refactoring Bootstrap they’ll often choose to make a new component and then override the Bootstrap styles. This will happen until things get so messy that even though you might have a nifty
<Button> React component, there might be eight different style sheets impacting that component from god knows where.
When a team starts using Bootstrap in this way it gets incredibly difficult to see the damage and point it back to this single point of failure. You’ll just start finding that it’s harder to write good front-end code. You’ll find tons of hacks lying around in your codebase and you’ll furrow your brow before continuing writing more code somewhere else.
Now, I don’t blame Bootstrap for this — I blame how Bootstrap is used.
The way we should use it is by taking only the pieces we need, specifically, the component styles. We shouldn’t
npm install this stuff either. I think we need to vendor it.
What does “vendoring” code mean? Well, the other day I stumbled upon this term in a blog post by Tom MacWright:
Vendoring, in the programming sense, means “copying the source code of another project into your project.” It’s in contrast to the practice of using dependencies, which would be adding another project’s name to your package.json file and having npm or yarn download and link it up for you.
This is exactly how I think we should be using CSS framework-esque projects like Tachyons and Bootstrap: just go and copy/paste only the parts of that code that you need.
Whenever I join a team this is almost always the first thing I do when it comes to design systems. I vendor Bootstrap, copying and pasting and deleting only the stuff we need and moving all those global styles into React components so that they can be read and understood easily in the future.
Vendoring code in this way might sound gross but it’ll be easier to make changes in the future, easier to read, and oddly enough easier to update if that specific library changes, too.