There are a lot of different ways to structure your CSS, and countless opinions on approaches to namespaces, methodologies etc.
A mix of all, depending on where and what I see fit. 😅 i definitely have utility classes. I use basic BEM. I’m influenced by ITCSS’s archiecture…
— Sara Soueidan (@SaraSoueidan) February 14, 2019
Historically here at Neoteric, we used Foundation and our own custom CSS toolkit to jumpstart projects. This gave us the advantage of being able to quickly spin up sites, even when not working with a graphic designer.
Our typical file structure in this set up would be:
Each partial in our toolkit would be imported into either _site.scss, or _toolkit.scss. Those in turn would be imported to application.scss, along with foundation’s import files. We didn’t adhere to any particular naming pattern other than the semantic names of elements. We used frequent and deep SASS nesting, and used HTML elements as selectors. We would group styles loosely on “models” or “components,” and would create a new stylesheet whenever we thought it was appropriate.
This is how many projects are built: a combination of historical practices and organic evolution set the tone, as opposed to an intentionally thought out architecture supported by pre-planned conventions and best practices. While this works fine for a small team working on marketing and communication websites, problems arise as teams grow and work on complicated web applications.
On new projects with no historical front end debt, yet very large scopes, using this old method negatively affects long term maintenance, performance, and complexity.
And so, this year, we are transitioning to a more scalable CSS architecture.
Modernizing our front end architecture
Planning a modern CSS architecture is tough! Our main goals are that it:
- Works especially well on ground up builds of complex web apps.
- Is maintainable and scalable.
- Is compatible with the Design System approach to UX, so we can prototype and design quickly.
We picked MaterializeCSS because it implements the popular Material Design System. It allows us to quickly design screens, prototype interactions, and get client feedback on application workflows.
For our own toolkit we decided to implement the BEMIT methodology. There are plenty of articles about BEM and ITCSS, but here is how it looks for us right now.
This will help us synchronize our Design System and our front end code in a scalable and sane way. For client work, especially for small teams, it can be tempting to just wing the CSS and work on issues and bugs as they arise. However, adopting modern CSS architecture practices from larger product and SASS teams creates a foundation for maintainability, performance, and knowledge transfer to new team members.
In my next article, I’ll cover why and how one might use different approaches to front end architecture.