With the rise of CSS-in-JS libraries such as styled-components and Emotion, there has been a growing debate about which approach is better for web design. In this discussion, let's hear your thoughts on whether CSS or CSS-in-JS is the better approach for web design in 2023.
Have you used CSS-in-JS libraries in your projects? Do you prefer using traditional CSS or do you find CSS-in-JS to be a better approach? Share your experiences and opinions in the comments below and let's discuss the pros and cons of both approaches.
Top comments (28)
While it depends, I think it's always worth considering erring on the side of the intents of the platform, and what the browser expects, prefers, and is developing.
I've always thought proper native CSS (with compilers and libraries as needed) is still the right default approach.
Yes
did not understand anything
Check out this article about CSS-in-JS from last year for some good arguments against it:
Why We're Breaking Up with CSS-in-JS
Sam Magura γ» Oct 16 '22 γ» 14 min read
The biggest argument from that article is about performance. While there may be some performance issues, if you use emotion in a certain way, this "way" of using emotion (using css method inside render) can easily be avoided. Its also not true that emotion doesn't work with SSR. I've used it just fine with Next's SSR, SSG and ISR although admittedly, it does require some extra configuration.
I rarely used CSS-in-JS since I would just use Tailwind and DaisyUI right now. If I don't use React, I use CSS in the way framework wants me to do (e.g.
stylein Vue and Svelte)For large projects or projects I don't want to focus on styling, I use component libraries. I would need to use CSS-in-JS that my component framework used. Basically, if you don't want to design things yourself, CSS-in-JS probably came with UI kit except for DaisyUI or Tailwind-based ones.
If I do need to style my components, I would use CSS as it has better IDE support. CSS module would solve collision problem also.
I had exactly this idea till color schemes for the app became a requirement. Then I felt blessed that we went with low (ish) level css. Me and many people on my team, we where doing css for decades so any library, framework, you name it .. has ultimately zero value to us. Scss does make the encapsulation issue easier but it's not a requirement.
I prefer css or scss modules, css-in-js looks like inline styles for me. You fill one file with jsx or tsx, js or ts and css
Its not like inline styles at all though... People just pick and chose what they get upset about and use that as an argument to dismiss everything that doesn't follow their own convictions.
The main idea about my comment was that, with that, you fill one file with all, in the end, yes they are not same but filling one file with all part is not good for my preferences
You can put your styles in seperate files with CSS-in-js if you want. The reason people don't do that is because there's no benefit to it.
HTML that goes over the wires should be styled with CSS; HTML that gets generated from within JavaScript should attempt to benefit from these styles, then any additional styling will usually be specific to the element anyway, so it makes a bit more sense to keep it close to the associated logic (these days this will usually be a component).
both CSS and CSS-in-JS have their merits and are widely used in web design. CSS, the traditional approach, offers a familiar syntax, clear separation of concerns, and good browser support. It's ideal for simple projects and teams experienced in CSS. On the other hand, CSS-in-JS, which combines CSS and JavaScript, provides a more dynamic and component-based approach. It offers benefits like scoped styles, better encapsulation, and enhanced reusability. CSS-in-JS is well-suited for complex applications, dynamic theming, and teams that prefer a more JavaScript-centric workflow. Ultimately, the choice depends on the project requirements, team preferences, and skillsets available.
This is probably the most objective comment I've read in a while π
CSS-in-JS solutions can be beneficial in situations where scoping CSS becomes a thing. When for instance you have a large portal with multiple sub applications on one page that have conflicts in their CSS because they all want to override global properties.
There are ways around that even if you do not want to use CSS-in-JS. But then you're talking IFrames.
Personally I don't like to use it anymore, performance is one thing. In some cases you can see the styles changing as the page is loading.
So if scoping is not a thing I tend to avoid it.
As a developer, it sure does help when I can just manipulate the styles in the code, instead of the complex task of finding the styles and hoping I haven't broken anything else.
Both of those issues can be solved with a sensible element naming scheme and the scoping provided by that.
I mean, yes, but this is often hard to get right, or goes south with the human problems of software development.
yes
I have enjoyed using styled-components / emotion / theme-ui / stitches / scss / sass / less but, I am often solving issues with js that can be solved (mostly) with css. The only performance 'issue' I discovered was FOC on the page while jss was being parsed - could be solved with a root stylesheet. Once vanilla CSS adopts nested selectors and some kind of mixins, I'll probably stick with css. Unless you are super critical of load times/perceived page speed - then use whatever makes your site look the best in the shortest time/code.
If you have a performance-critical application with complex UIs, CSS would be a suitable option for wed design services in 2023.
On the other side, CSS-in-JS approach is better suited for applications that prioritize design systems over performance, or for applications where performance is not a critical concern.
Admittedly I haven't really written vanilla CSS in a long time, but I highly prefer CSS-in-js because it makes it (nearly) impossible to have any kind of styling collision. The benefit of being able to respond to runtime changes should also be an obvious one. What pisses me off is that people who dislike CSS-in-js, usually pretend that somehow CSS-in-js is something completely different to vanilla CSS... Its not. Its just CSS written inside JS code, so it can benefit from JS runtime. Oh yea and its camelcase instead of kebabcase :p
I go with scss every time, it is css with super powers...
This seems more like a Reddit post than it should be a Dev.to article, no?
I will pick whatever the framework provides.
I used CSS for my furniture online UAE WEBSITE!