Recently, we released Roux, a set of native CSS styles and architecture opinions. This was born from years of collecting CSS patterns, opinions, and general best practices that worked on virtually any project, no matter the framework or industry. And it’s something we continue to add to and adjust as CSS changes and our own use cases shift.
Roux is what we’d call a boilerplate – a generic and reusable piece of content (in this case, code), that can be used in any relevant project without much alteration. It serves as a solid foundation to build from, without having to start from scratch.
Do you have one or two patterns you’ve used from project to project? Great! You, too, can build a boilerplate.
What is a boilerplate?
Most of my favorite design terminology, like gutters, drop caps, pull quotes, come from newspapers and print journalism. Boilerplate is one of those…well, sort of.
Originally it’s a term from steamships in the 1800s. They were sheets of rolled steel to make boilers to heat water. These boilers generated steam for the ship’s engine.
By the late 1800s/early 1900s, some newspapers were using reclaimed steamship boilerplates for hot metal typesetting in their printing presses. Linotype machines (among a few others) allowed for this typesetting, pouring molten lead into a mold, and producing multiple typesets from that mold. Perhaps there was an article or an advertisement that you’d want to send out to multiple newspapers to set in their printing as they chose. These more widely became known as “boilerplates”, which were more conventional content that could be applied to a number of publications geographically.
The term has since grown from its newspaper beginnings, to being used in contract law with “boilerplate clauses” and now in code.
How it works in code
In development, boilerplates are generally defined as reusable bits of code, agnostic to the type of project. It’s something you can start a codebase with or insert along the way as needed. Some are extremely opinionated, some are looser. Some are very thorough, and some are sparse. What it all boils down to (heh) is having something that is useful to you that works in various contexts.
Boilerplates can be useful by:
- Standardizing opinions, rules, and best practices by your team’s agreed-upon conventions into a reusable starting point
- Which in turn can ensure a consistent user experience with predictable and standardized interactions and patterns.
- Reducing decision fatigue because foundational choices are made (like CSS architecture), freeing you up to focus on more impactful work
- Minimizing human error by reducing or eliminating the risk of manual mistakes with repetitive setup tasks
- Accelerating onboarding that allows you or your team to jump into a familiar structure rather than inferring conventions from scratch
How you might approach writing your own
You probably already have a handful of code bits or content that you’re writing in the same or similar way over and over again – you just haven’t documented it. Take a look at your own corpus of code and see what emerges.
- Audit what you repeatedly build after looking at past projects and identifying a few patterns, structures, or sections you’re commonly recreating.
- Capture the annoying or painful bits. Useful boilerplates can solve the setup steps you may dread the most.
- Cherry pick from your best work with successful past projects. Sometimes that’s taking patterns in their entirety or frankensteining together bits from various projects.
- For example, I had a modal element where I liked the slide in transition I did in one project and another where I felt it had better accessibility support, so I mushed them together into one pattern.
- Strip out the project-specific details for the parts you want to use and leave what’s universally useful.
- Include comments, notes, or annotations that explain why things are set up the way they are. This may be useful not just for other people reading your boilerplate, but future you who has since forgotten why you decided on a specific structure or syntax, etc.
- Treat it as a living document and update it as your opinions and standards evolve.
Most importantly, know that it doesn’t have to be complicated or involved. Your boilerplate can be just a few patterns that are helpful to just you. It doesn’t even have to be code – it can be designs or layouts that you build prototypes with; it could be structures for documentation that you commonly write out. And while we did just talk about iterating on your boilerplate, it can absolutely be something that you write once and never adjust.
Boilerplates in the age of AI
Why bother writing out a boilerplate if Claude or any other LLMs can do it for you? The output reflects patterns it’s trained on, which are not necessarily your patterns. It doesn’t know you or your team’s specific decisions you’ve made over the years. Articulating what good and useful looks like for you forces you to refine those standards and create a more solid source of truth.
Sharing your patterns
Even if your boilerplate may only have a narrow use case for yourself, opening it up to feedback can sharpen your own thinking. Others might spot a gap or inconsistency you’ve been too close to notice. Sharing can also help others adopt your useful patterns in their own work. More broadly, it invites people to build, adapt, and improve it. You may surprise yourself at how novel your own workflows are to others!