128: Alasdair Monk - Scaling CSS at Heroku with Utility Classes

Topics include:Why Heroku introduced BEM to try and solve their CSS issues and why it didn't workHow custom tooling and Ember's component system alleviated any maintainability concerns about littering the HTML with presentational classesWhy Heroku still uses some component classes like "btn" and "input" even though they could encapsulate those in an Ember componentWhy 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 maintainableHow 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 systemWhy the team at Heroku still loves working with this approach, even 3.5 years after introducing itHow a utility-based approach has worked just as well for Heroku's marketing properties as it has for their application UIPylon, Alasdair's experimental CSS library that provides declarative layout primitives in the form of custom HTML elementsSponsors:DigitalOcean, get your free $50 credit at do.co/fullstackCloudinary, sign up and get 300,000 images/videos, 10GB of storage and 20GB of monthly bandwidth for freeLinks:purple3, Heroku's utility CSS library for their product UIsshibori3, Heroku's utility CSS library for their marketing propertiesPylon, Alasdair's declarative CSS layout library