Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Real-world CSS vs. CSS-in-JS performance comparison

pustelto.com

Post reply on HN
Print view View original

11–20 of 165 posts

Re: Real-world CSS vs. CSS-in-JS performance comparison

#11

Post by jahewson »

MatekCopatek wrote: post #5

Can 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?

For highly dynamic styles it allows me to avoid all the logic around coming up with class names and applying them. Think of it less like traditional CSS and more like a super version of inline styles.

Re: Real-world CSS vs. CSS-in-JS performance comparison

#12

Post by jonorsi »

This is an apples to oranges comparison -- a run-time compiled stylesheet vs. a statically-generated stylesheet. Styled Components has options for statically-generating their stylesheets (https://styled-components.com/docs/advanced#server-side-rend...), so why wouldn't you compare those?

Re: Real-world CSS vs. CSS-in-JS performance comparison

#13

Post by NegativeLatency »

jonorsi wrote: post #12

This is an apples to oranges comparison -- a run-time compiled stylesheet vs. a statically-generated stylesheet. Styled Components has options for statically-generating their stylesheets ( https://styled-components.com/docs/advanced#server-side-rend... ), so why wouldn't you compare those?

Might not be a fair comparison, but there are people who are looking at changing up how their css is written so it makes sense to be aware of the differences in performance.

Re: Real-world CSS vs. CSS-in-JS performance comparison

#15

Post by 11235813213455 »

TimTheTinker wrote: post #9
MatekCopatek wrote: post #5

Can 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…

like you say, the benefit is to easily attach styles to components (in the same programming language, compared to scss/css modules)

note: @emotion/styled is equivalent to styled-components, lighter and easier to set up for SSR (it works out of the box https://emotion.sh/docs/ssr#default-approach)

When using server-side rendered pages, there's no performance loss on the client-side, maybe a little more processing server-side, not sure if significant

Re: Real-world CSS vs. CSS-in-JS performance comparison

#16

Post by WorldMaker »

MatekCopatek wrote: post #5

Can 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?

Some of the React libraries do support CSS extraction to plain CSS files.

styled-components does not, and I'm not sure exactly why. It may be related to that they support runtime variables inline as React props and/or that they didn't want to complicate the build pipeline more than they already complicate it. (Many of the libraries like Vue's have necessarily tighter coupling with webpack or whatever other packer they use to get the extraction automated.)

Re: Real-world CSS vs. CSS-in-JS performance comparison

#17

Post by alexchamberlain »

TimTheTinker wrote: post #9
MatekCopatek wrote: post #5

Can 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…

Doesn't SCSS support CSS modules to prevent trampling on each others styles?

Re: Real-world CSS vs. CSS-in-JS performance comparison

#18

Post by hudixt »

A 4 year experienced react dev here. I have had decent time working with different styling

I'll try to answer few common things for everyone's context

Why even use CSS in JS?

- SPA bundling usually loads all CSS at once and all styles collide. You need to be super good at naming stuff/or load CSS based on module. So your CSS will be conflicting, so scoping is helpful here.

- Not having to jump from your component file to CSS file. Save some context switching or few strokes.

- Dynamic control over style. Basically your stylesheet is JS function returning style. You can do anything here. See this https://github.com/styled-components/styled-components/issue...

- Support for JS reference in color, font sizes, etc with editor support. It'll lead to more consistent design system.

- More cleaner API when using media queries, pseudo states. eg-https://emotion.sh/docs/media-queries

Another alternative is Emotion, also I find it to be much more cleaner in code perspective. (Good performant library in terms of layout and painting).

Why is export option not available for most CSS in JS (some suggested this as solution)?

Read this https://github.com/emotion-js/emotion/blob/bcf40cf2c20153481...

Is it worth it?

- Depends a lot on context and your perfonal objective. Generally I personally feel it's worth it as it's good tooling.

- CSS in JS is lot better than what it used to be. Styled component had good perf bump in last few years.

Re: Real-world CSS vs. CSS-in-JS performance comparison

#19

Post by stevebmark »

lwhi wrote: post #7
MatekCopatek wrote: post #5

Can 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.

CSS and Javascript aren't concerns, they're technologies, and separation of technologies isn't a software engineering principle. "Concern" is pretty undefined in general. If anything, they're all part of the "view" concern. It's the same reason why JSX doesn't violate separation of "concerns."

Re: Real-world CSS vs. CSS-in-JS performance comparison

#20

Post by andrewingram »

jonorsi wrote: post #12

This is an apples to oranges comparison -- a run-time compiled stylesheet vs. a statically-generated stylesheet. Styled Components has options for statically-generating their stylesheets ( https://styled-components.com/docs/advanced#server-side-rend... ), so why wouldn't you compare those?

You linked to server side rendering, not static extraction of styles, did you mean something else?

The point of static extraction (something the current wave of new CSS-in-JS libraries seem to be focusing on), is to generate all the style sheets at build time and serve them as regular CSS files — so that your styles don’t inflate your JS bundles (a problem most older CSS-in-JS libraries have).

Post reply on HN