Real-world CSS vs. CSS-in-JS performance comparison
1–10 of 165 posts
Re: Real-world CSS vs. CSS-in-JS performance comparison
#2> Don’t use runtime CSS-in-JS if you care about the load performance of your site. Simply less JS = Faster Site. There isn’t much we can do about it. But if you want to see some numbers, continue reading.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#3I wrote SnackUI[0] to solve this exact problem.
It gives you in my opinion a nicer style syntax (flat style props on the component) while avoiding the downsides of CSS-in-JS by extracting everything but the most dynamic parts to pure CSS.
The optimizing compiler part was a large investment to get right, especially with theme and media query support. But the main claim to fame is that it also works on React Native, and optimizes there as well, so you get for the first time a really performant way to style native and web apps at once.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#4If largest contentful paint is over 6 seconds, is Css-in-JS really the problem?
Re: Real-world CSS vs. CSS-in-JS performance comparison
#5Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets.
Is there something extra these React libraries do that prevents them from doing this?
Re: Real-world CSS vs. CSS-in-JS performance comparison
#6Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets. Is there something extra these React libraries do that prevents them from doing this?
Css-in-js helps minimize context switching for logic related styling, believe this is one of the main advantages from a developers perspective. It also allows javascript developers to colocate their CSS where they want, separate file, inline, same file, etc. This is more flexible than a .vue file in that sense.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#7Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets. Is there something extra these React libraries do that prevents them from doing this?
I've never really been comfortable with the idea, as I was raised on the idea that separation of concerns is good thing.
I think one of the main appealing aspects is the idea of never having a styling conflict with other components ever.
Less macro-level management and organisation required.
--
Edit: sorry, just realised you're talking about a specific implementation.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#8Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets. Is there something extra these React libraries do that prevents them from doing this?
Main thing that I think would prevent it is the ability to use React Props/Arguments in your CSS.
e.g. const Container = styled.div` width: $props => props.width `
Re: Real-world CSS vs. CSS-in-JS performance comparison
#9Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets. Is there something extra these React libraries do that prevents them from doing this?
We're migrating to styled-components at my current company. It's nice for abstracting components -- either into shared libraries or separate micro-clients that are composed together at runtime.
In those scenarios, there are a few benefits: (a) no worries about accidentally trampling on someone else's styles, or styles from elsewhere overriding your styles; (b) build configuration is simpler; and (c) no worries about how CSS/SCSS is referenced/loaded - all references are handled in plain JS with no special loaders or anything.
I wouldn't use it everywhere (I've used other approaches that have worked just fine), but for some scenarios it makes sense.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#10> Don’t use runtime CSS-in-JS if you care about the load performance of your site. Simply less JS = Faster Site. There isn’t much we can do about it. But if you want to see some numbers, continue reading.
Studies show computers running less code perform faster