Read in light, dark or mid-day theme
Artwork by Lucas Benjamin
This blog post will be about my reasons to move from Styled Components to SCSS Modules. Its gonna be a raw and non-technical one (i.e., you probably won't learn anything new from it).
What is styled-components?
Styled Components is a radical, new way of writing CSS for your React components. You can simply create components out of your styles
export const Main = () => {
return <HelloWorld>Hello World</HelloWorld>;
};
const HelloWorld = styled.h1`
font-weight: 700;
line-height: 1.618;
`;
This is a very, very convenient way of writing CSS. All your CSS lives in the same file as your main logic. It's ultimate Colocation. Plus if you're a freak about small components, this really enforces you to write small components, cuz the components grow large very quickly thanks to all 3 techs in a single file: HTML + CSS + TS(Yes, I'm one of those people who breath TypeScript ๐). So you kinda feel obligated to break your components into smaller pieces, which is ultimately good. Modularity is paramount.
Its just like Svelte and Vue's SFCs. They figured it out correctly, while this makes me mad about React.
Anyways, rant aside, this way of writing styles is really good, I can't insist enough. Need dynamic prop based styles? No worries, just pass props over to your styled component, and use it in there
export const Main = () => {
return <HelloWorld weight={600}>Hello World</HelloWorld>;
};
const HelloWorld = styled.h1<{ weight: number }>`
font-weight: ${({ weight }) => weight};
line-height: 1.618;
`;
Pardon the TypeScript code if you're not familiar with it or hate it. It can't be helped. Its part of my very being now ๐.
And yes, it automatically does the scoping and vendor prefixing. vendor prefixing is runtime generated, that is it determines if the browser needs vendor prefixes, then it will churn out styles with vendor prefixes. Its like a sweet runtime PostCSS and Autoprefixer running in the browser.
It makes stuff very very easy. But this is where it starts to go wrong if you don't fully understand how React and its rendering processes work.
What are CSS Modules?
CSS Modules are a slightly-less radical way of writing CSS. Its basically separate CSS files, but only modular. Syntax remains the same mostly, but it's scoped to the components where it is used (By mangling class names). The general pattern of these is this:
|-HelloWorld
|-HelloWorld.tsx
|-HelloWorld.module.css
Notice I use
.cssat the end. It could be.scssor.lessor.styltoo, you name it. I personally use SCSS modules.
Notice that our CSS Module has in the name itself that its a module, *.module.*. Its a Convention over Configuration approach, very prevalent in futuristic bundlers like ESBuild, Vite, Snowpack, etc.
And to use them, you import the css file in JS, and refer to it like this.
import css from './HelloWorld.module.css';
export const Main = () => {
return <h1 className={css.helloWorld}>Hello World</h1>;
};
Meanwhile our CSS file:
/* HelloWorld.module.css */
.helloWorld {
font-weight: 700;
line-height: 1.618;
}
The generated CSS is something like this:
/* HelloWorld.module.css */
.__B56BLAH_helloWorld_4269BRUHBRUH {
font-weight: 700;
line-height: 1.618;
}
The className is mangled, and the value is substituted in place of css.helloWorld in our component.
Alright I took some artistic liberty and added some weird Elon Musk-y stuff there. The actual mangled output would be much smaller and sane ๐.
CSS modules are very handy for this. Plus you can add tooling like autoprefixer to add vendor prefixes, compile stuff back to old CSS for browser compatibility.
The app in question
Now the intro is over, let's look at the app which I moved from Styled components to CSS modules. Let me introduce you to my baby, macos.now.sh, a macOS Big Sur clone written In Preact, TypeScript and uses Vite as the bundler. Check it out, I think you'll like it (Tip: Just hover over the app dock at the bottom).
Anyways, this whole app was written in Styled Components, until I threw it out of the 30+ components in favour of CSS Modules.
Why? ๐ง
The simple answer ๐
Just kidding ๐ . Here's a full technical explantion ๐
CSS not minified
Take a look at this image ๐
This the main production bundle of the app. As you can see, it's minified in some place, and not, in other places. You can see the unminified part is the CSS part. These are the styles I wrote as template literals(Or string literals, I mix both up ๐
). As these aren't CSS to bundler's internal CSS minifier, it stays as it is, which is kinda bummer. I am a die-hard performance freak, and the 1st rule of performance on Web: Bundle and minify your resources. Make them as small as possible, then make them even smaller ยฏ\_(ใ)_/ยฏ.
Seriously, you can check this file out right here: https://macos-web-fwyxhwxry-puruvj.vercel.app/assets/index.da0c587c.js
Why not use the babel plugin? ๐คจ
If you don't know, Styled Components has a Babel plugin for this purpose exactly, minifying the CSS inside the template literals, and its pretty decent.
But it wasn't working for me.
No literally, it wasn't working for me, as in I set up the babel plugin and did the correct config, installed the plugin, but no it wasn't working. Something was going wrong with Vite's plugin running. The plugin was working, as build times had increased a lot from before, but the output was still not minified. The same plugin worked perfectly in a create-react-app reproduction I created to check this.
But anyways, even if this problem was solved, there's a bigger Elephant in the room
CSS injected by JS
All of this CSS still lives in the JavaScript, and is only applied when JS is evaluated by the browser, and I'm pretty sure you know of this, JavaScript is HEAVY!!!. It takes quite some CPU power to parse it, and it's heavy on main thread. Our HTML being rendered by JS itself is pushing the limit, but rendering CSS using JS too? That's way too much load on the browser.
Browsers have become amazingly efficient at parsing JS as well as rendering HTML and CSS, all in parallel. But JavaScript doing all the work, well, browsers still aren't that efficient at it(For good reason).
If you want ultimate performance, CSS in separate files or inlined in style tag is the way too go. It doesn't get better than that.
Performance had become important
When I started this project almost 6 months ago (November 2020), I made myself a little deal: Do not stress about the performance. Off course, at that time, Performance meant just lower bundle sizes, not runtime performance, cuz I really had never run into any runtime perf issues before. But this project is different in the sense that there's a lot going on. There are loads of requestAnimationFrames, tons of component, lot of global state, and what not going on. And all of it is on the screen at once. You can't really lazy load much stuff, cuz almost everything is eagerly loaded.
All of it was weighing down the runtime perf of the app. The dock animation was janky, the menus took a while to open up, theme switching was also noticeably janky. So I had to finally consider the runtime performance. And the most obvious choice was to start throwing out fancy stuff and move back to basics again.
Did it work?
Absolutely!! The performance increased like crazy. Both runtime as well as bundle size.
This is the compressed CSS file output. Its run through Autoprefixer for vendor styles, and Vite automatically puts it into a single CSS file, super compressed. Take a look yourself ๐
And here's the index.js ๐
Completely minified, JS lives in js files, CSS lives in its own file, and its all processed parallelly by the browser, styles aren't generated for every prop change like in styled components. Only the classes are applied, and the styles for that are already present in the CSS file. Just like the old times, simply and fast.
Reduced Bundle Size
This total maneuver took away 60KB from my bundles, which is just huge. I removed styled-components, react-is(Styled components require it for some reason), styled-reset and color2k(For color manipulation).
If you have been coding for some time, you'll know how incredibly satisfying deleting old stuff is. ๐
What did it cost?
Yup. I lost something: A great API design.
Writing styles in Styled Components is a pleasure. The API design is amazing, and I prefer it over CSS modules in terms of writing the code.
If you aren't using a style, means you aren't using a component, so the component will be called out by VSCode as not being used, so you can easily remove it. No more dead styles!!
Plus, compare the component below in Styled Components:
interface ActionCenterSurfaceProps {
grid: [[number, number], [number, number]];
children: ComponentChildren;
}
export const ActionCenterSurface = ({ grid, children }: ActionCenterSurfaceProps) => {
const [[columnStart, columnSpan], [rowStart, rowSpan]] = grid;
const [theme] = useTheme();
return (
<Container
columnSpan={columnSpan}
columnStart={columnStart}
rowSpan={rowSpan}
rowStart={rowStart}
theme={theme}
>
{children}
</Container>
);
};
type ContainerProps = {
columnStart: number;
columnSpan: number;
rowStart: number;
rowSpan: number;
theme: TTheme;
};
const Container = styled.section<ContainerProps>`
display: grid;
grid-auto-rows: 1fr;
gap: 0.25rem;
position: relative;
padding: 0.5rem;
border-radius: 0.75rem;
background-color: hsla(${theme.colors.light.hsl}, 0.5);
${({ columnStart, columnSpan, rowSpan, rowStart, theme: localTheme }) => css`
grid-column: ${columnStart} / span ${columnSpan};
grid-row: ${rowStart} / span ${rowSpan};
box-shadow: hsla(0, 0%, 0%, 0.3) 0px 1px 4px -1px, 0 0 0 ${localTheme === 'dark' ? 0.4 : 0}px hsla(
${theme.colors.dark.hsl},
0.3
);
`};
`;
This is one of my components in Styled Components before. As you can see, it accepts values that are numbers. If there were booleans, it would've been easy to make a class and apply the styles then. But here, the value can be anything.
And now look at the new CSS Module version:
Component:
interface ActionCenterSurfaceProps {
grid: [[columnStart: number, columnSpan: number], [rowStart: number, rowSpan: number]];
children: ComponentChildren;
}
export const ActionCenterSurface = ({ grid, children }: ActionCenterSurfaceProps) => {
const [[columnStart, columnSpan], [rowStart, rowSpan]] = grid;
const [theme] = useTheme();
return (
<section
className={css.container}
style={
{
'--column-start': columnStart,
'--column-span': columnSpan,
'--row-start': rowStart,
'--row-span': rowSpan,
'--border-size': `${theme === 'dark' ? 0.4 : 0}px`,
} as React.CSSProperties
}
>
{children}
</section>
);
};
And the CSS for this component:
.container {
display: grid;
grid-auto-rows: 1fr;
gap: 0.25rem;
position: relative;
padding: 0.5rem;
border-radius: 0.75rem;
box-shadow: hsla(0, 0%, 0%, 0.3) 0px 1px 4px -1px, 0 0 0 var(--border-size) hsla(
var(--app-color-dark-hsl),
0.3
);
background-color: hsla(var(--app-color-light-hsl), 0.5);
grid-column: var(--column-start) / span var(--column-span);
grid-row: var(--row-start) / span var(--row-span);
}
As you can see, the prop values are passed to the CSS using CSS variables. This method is good too, but the Styled Components method is cleaner in my opinion.
In future, I might try out libraries like Linaria which, during coding have the exact same API as styled-components, but the runtime is completely removed on build and the CSS is extracted into separate CSS files, which is super DOPE!!! ๐ค
Alright, that's it for today.
Signing off!! ๐
Oldest comments (52)
Nice explanation. Plus the macOS clone is great, super. For styling you can check this css-in-js solution stitches.dev/.
Thanks!!
This is a nice library. Not sure I would use it though, I dislike writing styles in an object. The intellisense is all over the place and all. Styled components ha overall better intellisense in VSCode. Just my opinion :)
My current fav approach as well ๐โค
One of the great benefits of CSS modules it that you have the compose
A way to combine additional class for your file or any other file without specified it in the components itself
Yes. That is really amazing, and I love that. Its a very smooth alternative to
styled(ComposedComponent)reallyJS has had enough tbh. It is generating the HTML, doing the CSS, minifying stuff, optimizing stuff. the least we can do is take CSS out of its plate ๐
Good read ๐
Yup. The whole essense of this article is your comment
(I should I've just written your commentas the whole article. Would've saved so much time and energy ๐)
I also prefer CSS modules. If someone want an introduction to CSS Modules, check out this article.
It also cost readability. It's ok if you end up writing simple semantic markup (but then, everything's ok if you do that). If you rely on multiple nested
divs with obfuscated class names then it'll be harder to debug and you'll annoy a lot of "tinkerers"... tinkerers like you and me.It's the sort of thing people do to prevent the use of ad blockers, or stop people from re-skinning a site with user styles.
Personally, I want people to be able to change the look and feel of any page I make, because people have different needs, abilities and limitations.
Aye!
Not sure what you mean here, the thing with the class names getting garbled is something every styling solution (that supports scoped styles) does, because it's the only way to automatically avoid class name collisions without resorting to something like shadow DOM.
Unfortunately, the only way to avoid this is either to go back to unscoped CSS with something like BEM to avoid collisions, or to manually add stable identifiers to your components (for UI tests, supporting user styles, etc.), as either class names or data attributes.
I think he means it in relative terms. You can still make sense of CSS modules scoped styles, they're just same names with some junk appended here and there, where with styled components, there's no chance you could ever guess what this class stands for
I mean it in "why not go back to regular CSS" terms.
... to do things the way they were designed to be done? I don't see this as so much of an unfortunate reality as I do a code smell.
Because "regular" (unscoped) CSS is incredibly cumbersome for large projects, and it gets even worse if you add more devs to the team. BEM and other CSS methodologies took us some of the way towards fixing this, but they're cumbersome in their own right, and only help so much. CSS-in-JS and CSS modules are the first solutions we've come up with that make CSS work well at the scales often we write it today.
CSS (and most web technologies, for that matter) was never designed to be used for many of the things we use it for today. Using everything as it was originally designed isn't really compatible with modern webdev.
๐๐๐๐๐
I started to improve my CSS skills and it only got better after I understood the modules and applied them, exponentially my learning process went up, with SASS it got even better to use it.
Yeah. Screw the people who say learn HTML, then CSS then JS, then React, then frameworks and blah blah. Best learning path is just mix and match everything and go crazy. So great it worked for you
I believe there are libraries out there to keep your css class imports type safe still.
Really? Please recommend some, I really need those. I have an extension for class intellisense, but its not as smooth really
Performance is definitely important, but I feel like you kind of threw the baby out with the bathwater here. As you pointed out at the end, we have CSS-in-JS solutions now that have zero runtime performance hit, so there's no need to ditch CSS-in-JS entirely if performance is your only real concern.
Yup. The thing is, I tried Linaria too. But my project heavily relies on path aliases, and whatever Vite's alias uses internally, wasn't compatible with Linaria, so the babel plugin threw an error and I couldn't debug the problem.
So I decided to just go ahead and merge the CSS modules PR into the code. I prefer Styled Components API, but CSS modules isn't bad either. The joy of writing plain CSS is also really nice and fast, and the intellisense is amazing, so not really missing out on anything for this project.
Ah, that's unfortunate. But yeah, CSS modules are cool too, I mainly just don't like them in React because I don't want to go back to writing CSS in a separate file.
No-runtime CSS-in-JS seems like a good compromise! Are there any cons you aware of? What comes into my mind โ they patch JS code which is fragile IMO.
I tried Linaria, but it didn't work with Vite with the aliases and all, so had to settle for CSS Modules. No regrets though, CSS modules are a great experience too :)
Very nice explained, you save my day.Thanks so much
Thank you
How about using compiled css-in-js? They only cost is build time.
I assume you're referring to libraries like Linaria and vanilla-extract?
no there's literally a libaray called
compiled css-in-jsOh yeah, Atlassian's solution. Its good too, but by the time I got to know about it, I had already merged the PR, wasn't going to go back. Plus I found it had similar issues about path aliases, so it wouldn;t have been very useful, still
I liked your post, it is great to know that Iโm not the only person concerned about the cost of css in JS. About readability and in order to avoid prefixes to isolate the components you can use a CSS architecture, like bliss github.com/gilbox/css-bliss .
Hmm it seems nice, but its a convention in the end, like BEM. Another thing to remember while coding. The reason I turned to Styled Components and CSS Modules is to not think about this stuff, just put some dumb selectors at place and expect nothing to break.
I don't do well with CSS based conventions. never have ๐
I agree in the performance side.. My experience is, when the project is getting really really big, styled components are a lot better to maintain.
Definitely, if its a team. For this project, its just me(Well, now there are more thankfully :) ), so maintainability isn't a huge problem. Plus I force myself to keep my components less than 60 lines(Roughly, not a hard limit), so the CSS is smaller too, so its automatically maintainable. Plus the CSS variables theming works pretty well, so that doesn't get in the way too ๐
Please could you explain why that is, thanks.
What did you use to display the code , I want to know how to do this
Type 3 backticks (`), type the langauge just next to them without any break (ts, ruby, js, html,css etc), put your code their, and close with 3 backticks
Author of CSS modules is working on Vanilla Extract, that could be a nice alternative
github.com/seek-oss/vanilla-extract
yeah, Mark is killing it. This project is amazing really. Only I wish its api was like styled components. Writing styles in JS objects isn't fun, in terms of intellisense ๐๐