In this episode, Adam talks to Alasdair Monk about how they approach CSS at Heroku, and how using a utility-based approach has kept their team happy for the last three years.
Topics include:
- Why Heroku introduced BEM to try and solve their CSS issues and why it didn't work
- How custom tooling and Ember's component system alleviated any maintainability concerns about littering the HTML with presentational classes
- Why Heroku still uses some component classes like "btn" and "input" even though they could encapsulate those in an Ember component
- Why simply introducing any sort of rigid CSS architecture wasn't enough and why switching to a utility CSS approach specifically was critical to making UI development at Heroku more maintainable
- How with a non-utility CSS approach, every new feature always seemed to require writing new CSS, no matter how many "reusable" components existed in the system
- Why the team at Heroku still loves working with this approach, even 3.5 years after introducing it
- How a utility-based approach has worked just as well for Heroku's marketing properties as it has for their application UI
Pylon, Alasdair's experimental CSS library that provides declarative layout primitives in the form of custom HTML elements
Links:
Links: