Rework

December 10, 2014

@hazelcough, Michelle Bu

Slides

At Stripe, there were a lot of developers who needed that tiny bit of CSS to ship something.

There was a lot of nesting. Almost arbitarily, causing things to be designed three times over. Meant you could never grep for anything. This problem caused the three levels of CSS degredation:

Determination

MVP features. Yay, we brought in Sass and we shipped the thing!

Development

We improve features, introduce a few bugs, and there's some code stink but it's okay! We'll fix it later.

Denial

Everything still works! Errr monkey no see/no hear/whatever, it's fine. It's fine.

Despair

Everything is growing so friggin' fast. CSS is growing at three poops per week.

We need to treat CSS like a first-class tool. We write Javascript with linters and with tests; CSS needs these things too!

We need conventions. So, at Stripe they started a component library.

Developers who didn't know CSS used it in their other internal projects. It meant that they didn't have to bother designers for it when they just wanted to get something up quickly.

-No- Conventions

Coming up with a convention style speed up developers and kept people from arbitarily adding CSS to the bottoms of Sass files.

Abstracting away components allows them to easily change things.

Enter the Rework framework!

-No- Tests

Testing is hard because of all of the states CSS has.

So, why care?

There are already a bajillion component libraries, I thought!

With your own component library, you're able to spend 90% of your time building the components and 10% on polish. If we think about CSS first, we can think about CSS less.