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:
/stylesheets /_site _buttons.scss _global.scss _home.scss _nav.scss _news.scss _site.scss /_toolkit _colors.scss _forms.scss _layout.scss _mixins.scss _normalize.scss _toolkit.scss _typography.scss _ui.scss foundation_and_overrides.scss _settings.scss application.scss
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.
/stylesheets /_toolkit /_base _forms.scss _layout.scss _typography.scss /_components _header.scss _progress-indicator.scss /_generic /_objects _buttons.scss _flashes.scss /_settings _colors.scss _typography.scss /_shame _shame.scss /_tools _mixins.scss _utility.scss _toolkit.scss application.scss materialize.scss
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.