Making CSS Fit at Unbounce

Remember those days when we stuffed our faces with whatever could be found in mom’s cupboards with no repercussions? We were so young and our poor bodies could handle whatever we threw at it: pizza pops, a tray of oreos, bowl of chips, half of pan of rice krispie squares, loads and loads of css declarations. We were a mess, but did whatever it took to fill us up as quick as possible lest we become hangry.

Now that we’re older and a bit wiser we found ourselves needing to rethink our eating habits in an effort to slim down. Likewise, Unbounce found itself needing to rethink how we approached front-end dev.

As we scaled through our teenage years our css habits got out of hand. We stepped on a scale and saw a hefty 93 kb staring dully back at us. How could this happen to us? Classes were nested inside other nested classes so we couldn’t effectively modify elements. Components which looked and functioned similarly were defined in several spots. We had 168 unique colors and 43 unique font sizes. We didn’t know how to use third-party plugins because there was no documentation. Oh god: Everything was extended.

With our new fiscal year starting, we made a new year’s resolution to slim down and be healthier. We wanted our new approach to:

• Use a modular, componentized system for high re-usability
• Abstract the front-end away from the back-end logic so teams could focus on their interest without getting in the way of each other
• Be self-contained in terms of HTML, CSS, and low-level JS so the UX team could own the entire component
• Allow visual upgrades quicker and without affecting the app
• Include documentation

We now have a style guide, (which is still a work in progress) and have started to individually integrate the new SASS components into our webapp. Easy, right? No. It caused a bunch of headaches and even downtime.

Our old SASS is in a conflicting state with the new SASS so we’re needing to find hacky workarounds for implementation. For example, any redefined classes now need a version modifier class and their old declarations to be reinitialized so we can have new components in some places and old components in others. Or trying to move files has revealed unexpected dependencies. We need a legacy override file to override deep-nested classes. This approach is making relatively simple UI changes take exponentially longer and our new, fresh, and clean code is starting to look messy and ugly already.

The thinking behind this approach was that a gradual integration would be less risky and easier than a starting fresh approach. We’d be able to test things more thoroughly and slowly as new components were integrated. Unfortunately, that doesn’t seem to be the case at all; We’d have to do a find and replace and test the entire app at once once the new SASS was fully integrated.

So we’re starting again. Approach #2 is to migrate our guide into a component library, like Rizzo by Lonely Planet and completely integrate each component throughout the app in batches. We’re hoping to come out of it with clean, semantic, modular code that is easy to adjust and easy to apply.

Once we’re further along I’ll get to the details on how we rolled it out!

Brian Holt
UX Developer