Lightning CSS

It’s not often I’m in the market for CSS processing tools. I was very into Sass but stopped using it when CSS became more capable and PostCSS became more useful to me.

PostCSS is very useful for me and the wider team. Here’s what our postcss.config.mjs file looks like for this website:

import postcssGlobalData from '@csstools/postcss-global-data';
import postcssImportExtGlob from 'postcss-import-ext-glob';
import postcssCustomMedia from 'postcss-custom-media';
import cssnano from 'cssnano';

const isProduction = process.env.NODE_ENV === 'production';

export default {
  plugins: [
    postcssGlobalData({
      files: [
        './src/global/variables.css'
      ]
    }),
    postcssImportExtGlob(),
    postcssCustomMedia(),
    isProduction && cssnano()
  ]
};

This setup allows a couple of useful features for us such as defining non-standard custom property-like variables for media queries, for when we actually need them.

The main thing PostCSS does for us though is importing globs, such as this:

@import-glob 'compositions/*.css';
@import-glob 'utilities/*.css';

It means any CSS file added to either the compositions or utilities directory gets automatically bundled. Our blocks are specifically imported in each respective React component.

What’s interesting about Lightning CSSpermalink

To test minifying and I guess bundling speeds, Lightning CSS test by minifying Bootstrap 4. It’s a good test because by proxy of Bootstrap being a design system in a box, it’s huge.

Lightning CSS claims to do this is in 4.16ms vs CSS Nano’s 544.81ms. That’s a huge, 99%+ difference!

This is less relevant for us because build times are quite fast — albeit 1.84s, which could be improved in my opinion. I’m looking at this more for companies that have huge front-end codebases. A 99%+ improvement on build times can save eye-watering levels of productivity over time for large teams.

I also like this class composition feature. It reminds me of the infamous @extends from Sass:

.bg-indigo {
  background: indigo;
}

.indigo-white {
  composes: bg-indigo;
  color: white;
}

This example is taken from their documentation. There’s no mention of what the output looks like over time though on there, so maybe use this with caution.

The reason Sass @extends is infamous is because of this sort of pattern:

.my-button {
  @extends .base-button;
}

Looks pretty innocent, right? If say another 10 classes also @extends .base-button, you guessed it: a massive selector block would be rendered, making browser debugging near-impossible on massive codebases.

Overall, I think Lightning CSS is definitely worth taking a look at, especially if you’re working on large codebases. We’ll take a cursory look, but like I say, CSS bundling isn’t costing us much right now.

PostCSS is also very useful to us still, but if that changes and we want something more contained and not plugin-based, we’ll certainly be giving Lightning CSS a proper look.