Philosophy

The ideas behind Live Wires and why it exists.

The anti-framework

I originally built Live Wires in 2013 as a reaction to Bootstrap. It solved real problems—but it solved them by making decisions for you. It dictated not just design choices, but markup patterns, class naming conventions, and architectural assumptions.

The result? Every Bootstrap site had a Bootstrap signature. The frameworks that promised to speed up your work ended up homogenizing it.

These days, utility-first frameworks like Tailwind dominate. I actually like Tailwind—Live Wires is compatible with it, and I encourage people to graduate to it when they need more. But the issue I see is going utility-only and losing the benefits of semantic structure and good defaults.

Live Wires takes a different approach. Instead of giving you a complete design system to implement, it gives you:

  • Good defaults that make semantic HTML look presentable
  • Compositional primitives for common layout patterns
  • Design tokens you’re expected to customize
  • A philosophy for building your own system

The goal isn’t to use Live Wires forever. The goal is to build your own framework—one that reflects your process and preferences—using Live Wires as a starting point.

To top

Magazine heritage

I learned design through magazine layout and web development at the same time. That editorial background shaped everything about how Live Wires works.

Magazine design has always used systems. Every publication has a grid, a type hierarchy, a color palette. There are running heads, folios, department styles, and recurring templates. But within those systems, there’s variation. Every spread is designed. Every feature has personality. The system enables expression rather than constraining it.

That’s exactly how you’d lay out magazine sections—you understand there’s going to be variation in those pieces, and you want to abstract the content out at that stage.

Web design frameworks typically work the opposite way. They start with components and expect you to fill them with content. Live Wires starts with content and helps you build the components you actually need.

Editorial thinking

This magazine mindset influences several Live Wires principles:

Content first
Design decisions should respond to actual content, not placeholder text. Real articles have varying lengths. Real headlines have different word counts. Design for reality.
Controlled variation
Give content editors meaningful choices (color schemes, layout options) without letting them break the system. Like how a magazine designer might offer department heads a choice of three header treatments.
Vertical rhythm
The foundational unit (--line) comes from print typography, where everything aligns to a leading grid. Web developers often ignore this—magazine designers know it creates natural-feeling rhythm and makes design decisions easier.
Spreads, not screens
Think about how content flows across pages and sections, not just individual components. The .section primitive exists to create rhythm across a page.

To top

Make it your own

This is the most important thing to understand about Live Wires: don’t try to stay in sync with upstream.

The thing I try to get people to do when they use it is don’t override anything. Just go in there, gut it, and make it your own.

Live Wires isn’t a dependency you install and update. It’s a starting point you fork and evolve. Every team that uses it should end up with something different—something that reflects their process, their preferences, their stakeholders.

What this means in practice

  • Delete what you don’t need. If you never use the sidebar primitive, remove it. If you hate the button styles, gut them.
  • Add your own patterns. As you build projects, extract the patterns that emerge into your version of the framework.
  • Don’t override, modify. Instead of writing CSS that fights the defaults, change the defaults.
  • Let it evolve. Your internal framework should grow with each project. What you learn on one project should benefit the next.

Your signature in the code

The details of how you write CSS, how you name things, how you structure templates—these are your signature. With frameworks like Bootstrap, you’re implementing someone else’s signature. With Live Wires, you’re developing your own.

A lot of those details really help dictate the final product. It’s like your signature when you’re building. Over time, you’ll have a proven set of assets that reflect how your team works. New projects start from a foundation you understand deeply because you built it.

To top

Progressive refinement

Traditional web design workflows are wasteful. You sketch, then throw away the sketch. You wireframe, then throw away the wireframe. You mock up in Figma, then hand off to a developer who rebuilds everything from scratch. Each phase produces artifacts that get discarded.

Live Wires inverts this. Every step builds on the last.

Think of it like sculpting a statue. You’re working with a big piece of granite. You start off with a really rough, really loose wireframe that you can click through—but you don’t want to throw that away.

The sculpture metaphor

Sculpting a statue doesn’t mean making a clay model, photographing it, then carving marble from the photo. You work the same material from rough to refined:

  1. Rough out the form — Block in major shapes (semantic HTML with layout primitives)
  2. Refine proportions — Adjust relationships (design tokens)
  3. Add detail — Surface treatment (utility classes, custom CSS)
  4. Polish — Final refinement (component extraction, production optimization)

At each stage, you’re working with the actual material that will ship. The rough wireframe contains real content, real HTML structure, real CSS. Refinement means evolving that code, not replacing it.

Why this matters

  • No translation loss. Ideas don’t degrade as they move between tools and people.
  • Earlier feedback. Stakeholders interact with the real thing sooner.
  • Faster iteration. Changes propagate automatically through connected styles.
  • Better estimation. You’re building as you design, so scope becomes clearer.

To top

Design machines

Live Wires emerged alongside a critique of modern web design: that our tools and processes have led to homogenization. Everything looks the same because we’re all using the same frameworks, the same patterns, the same templates.

On the web, because of our approaches to frameworks and CMSs, you kind of have to build a templated system. There’s not really much room for variation beyond. And because of this approach, we’ve hit a lot of sameness on the web.

Systems that enable variation

The solution isn’t to abandon systems—print design proves that systems and expression can coexist. The solution is to build systems that enable variation rather than suppress it.

This means:

  • Design tokens over hard-coded values. Make decisions in one place, then let them ripple through.
  • Compositional primitives over rigid components. Combine simple pieces rather than configuring complex ones.
  • Semantic HTML over div soup. Let content structure inform design, not the other way around.
  • Controlled variation for content editors. Give them meaningful choices without the ability to break things.

The question

Every project is an opportunity to push beyond sameness. Live Wires gives you a foundation, but the question remains: how will you be different from the machines?

To top

Related