Scaling CSS Architecture for Web Applications



Mia baker 322558 unsplash%281%29

There are a lot of different ways to structure your CSS, and countless opinions on approaches to namespaces, methodologies etc.

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.

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.

/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.