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 M...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)
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.
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.
🙌🙌🙌🙌🙌
Aye!
JS 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 😂)
In few months you are going to write another article how I moved from SCSS to pure CSS 😂
Nonetheless great article and thorough explanation, thanks 🙏
I might. Who knows 😉😉!! I only use SCSS for nesting, but with CSS modules even that isn't needed much, as the files are less than 60 lines big and most don't have any nesting in them
Though Vite has such a first class support for SCSS that moving to plain CSS won't be any hassle. I could do the whole thing in 2 hours :P
You can use PostCSS to deal with nesting and do a lot more
Why not use TailwindCSS with JIT compilation mode ? You write all styles inside component and final size of the css bundle is minimal
Well, a few points here:
classnames and allI'm asking what will you use if you will start a new project ? Tailwind has Intellisense class sorting plugins, this makes actual writing of text much shorter. You just type 1-2 letters and ther press TAB or use arrows to choose. Also it is much easier for other people to edit your code, they don't need to understand the whole structure of styles, everything is global.
I would still go for plain CSS Modules, because I use CSS vars extensively, and having some styles inline, and the variables styles in a stylesheet wouldn't be smart
I think if you try Tailwind in a big project, you will realize soon that it saves a lot of time that you don't need to switch between files. All styling inside component and no need for additional files
Oh I have used Tailwind on some medium sized projects. Coming back to Styled Components and now plain CSS once again is the next in progression.
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 😔😔
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.
Since you live typescript like me your should give this plug-in a go: npmjs.com/package/typescript-plugi...
It's adds some nice intellisense when working with CSS modules
I put it in the workflow. Its amazing. can't believe I didn't know about this before github.com/PuruVJ/macos-web/commit...
OMG!!! This is marvellous!!!!! I can finally get rid of that extension
I also prefer CSS modules. If someone want an introduction to CSS Modules, check out this article.
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 know this is an older post, but you should really try Vanilla Extract for zero runtime CSS in Typescript... it is like the best of both these worlds in one package.
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
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
Very nice explained, you save my day.Thanks so much
Thank 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
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)reallyMy current fav approach as well 🙏❤
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 :)
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