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

81–90 of 165 posts

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

#81

Post by notoverthere »

lwhi wrote: post #76
jfengel wrote: post #26

Earlier quoted context omitted.

I'm afraid I don't get it either. To me, the big disadvantage of css-in-js is that the browser doesn't display it neatly. If I write plain CSS, it's easy to make changes right in the browser and have it react instantly. Or I can make them in the .css file, and webpack (or whatever it is) will automatically redisplay them without having to restart the app. Perhaps if I had much larger projects I'd see more headaches t…

Imagine you need to implement an alternative stylesheet for people with increased visual needs (e.g. high contrast). How would you go about doing this? -- Edit: to the person who downvoted me for asking a question. Classy.

Switch the `` value to point to a high contrast stylesheet.

Or alternatively, apply a class to the body tag – e.g. `` – and declare CSS rules accordingly. Specificity should take care of overriding the 'normal' style rules where needed.

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

#82

Post by rajangdavis »

runarberg wrote: post #69
rajangdavis wrote: post #43

Earlier quoted context omitted.

If you want to have a range of applicable values for some CSS property or state-based styling, CSS-in-JS can be a good tool for expressing that as opposed to writing JS that updates some styling declaratively. For example, I've used it on a personal app to allow adjusting the placement and opacity of controls. I prefer the CSS-in-JS approach because the code is simple to understand, I can reuse the code in multiple a…

There are number of techniques that can fit that. State based styling can be achieved with simple class name toggles or CSS animation + the `animationend` event. If you don’t like toggling classes with JS there are number of selectors (including the attribute selector) which you can use instead. For making code easier to understand you can set a CSS custom property instead of specific style values, and the CSS will b…

To be clear - when I need to toggle a basic state with a class or set of classes, that is the strategy I use.

Where that technique fails is when you have hundreds of possible values that can occupy a given state.

If I want to set the rotation or opacity for a control and I want to use a range of values, there is nothing native in CSS to allow me to do that.

You can use SCSS to dynamically generate the CSS class declarations for every possible value, but I would only ever use that solution if I needed the performance boost and that was the only way to get it.

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

#83

Post by easrng »

lwhi wrote: post #76
jfengel wrote: post #26

Earlier quoted context omitted.

I'm afraid I don't get it either. To me, the big disadvantage of css-in-js is that the browser doesn't display it neatly. If I write plain CSS, it's easy to make changes right in the browser and have it react instantly. Or I can make them in the .css file, and webpack (or whatever it is) will automatically redisplay them without having to restart the app. Perhaps if I had much larger projects I'd see more headaches t…

Imagine you need to implement an alternative stylesheet for people with increased visual needs (e.g. high contrast). How would you go about doing this? -- Edit: to the person who downvoted me for asking a question. Classy.

I'd use CSS variables for colors and write another stylesheet, using the cascade so I only override the styles I need to.

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

#84

Post by runarberg »

The_rationalist wrote: post #64
rajangdavis wrote: post #43

Earlier quoted context omitted.

If you want to have a range of applicable values for some CSS property or state-based styling, CSS-in-JS can be a good tool for expressing that as opposed to writing JS that updates some styling declaratively. For example, I've used it on a personal app to allow adjusting the placement and opacity of controls. I prefer the CSS-in-JS approach because the code is simple to understand, I can reuse the code in multiple a…

Css variables can be exported and modified in js through some libraries and without having the constraints of css in js.

You don’t even need a library. Modifying a CSS variable is as easy as:

    myElement.style.setProperty('--my-custom-property', 'some-value');

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

#85

Post by runarberg »

rajangdavis wrote: post #82
runarberg wrote: post #69

Earlier quoted context omitted.

There are number of techniques that can fit that. State based styling can be achieved with simple class name toggles or CSS animation + the `animationend` event. If you don’t like toggling classes with JS there are number of selectors (including the attribute selector) which you can use instead. For making code easier to understand you can set a CSS custom property instead of specific style values, and the CSS will b…

To be clear - when I need to toggle a basic state with a class or set of classes, that is the strategy I use. Where that technique fails is when you have hundreds of possible values that can occupy a given state. If I want to set the rotation or opacity for a control and I want to use a range of values, there is nothing native in CSS to allow me to do that. You can use SCSS to dynamically generate the CSS class decla…

I see what you mean. For that I would use a CSS custom property:

    .rotatable {
      transform: rotate(var(--rotation-angle));
    }
...and set it directly with JavaScript

    document
      .querySelector('.rotatable')
      .style.setProperty(
        '--rotation-angle',
        `${angle}deg`,
      );

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

#86

Post by iaml »

lwhi wrote: post #75
eckmLJE wrote: post #32

Earlier quoted context omitted.

If you have a lot of dynamic styles that respond to application state, then even with vanilla CSS you are often writing JS to manage class declarations to get the right CSS combinations. With styled-components, instead of adding/removing/combining class names, you can write javascript inside your declarations that use the state variables. For me, writing javascript that directly sets css properties based on state var…

> For me, writing javascript that directly sets css properties based on state variables is a more powerful and clearer approach to managing dynamic styles than manually managing class names. I'd argue there's a lot more flexibility available if you choose to use classes. Sure, it's more complicated and involves more work; but to say it's less powerful just isn't true.

> there's a lot more flexibility available if you choose to use classes

That is simply not true. Apart from what was described in the post above, in JSS frameworks such as styled-components, you usually have ways to hook directly into css parser, allowing you to implement custom expansions, replacements or basically whatever logic you want. This is not possible unless you write your own language and transform it to css.

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

#87

Post by iaml »

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?

Nobody mentioned this, but for me big benefit is that you can remove everything related to css from webpack, and no dependency on ruby/dart/whatever else. Oh, also autoprefixer out of the box.

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

#88

Post by the__alchemist »

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 think there's a conflation that confuses this: We have CSS in SPA components vs CSS, and inline CSS in HTML. In the latter, you may prefer inline to prevent flipping between files, and creating reusable data structures that are used once. In the former, you may have the same, or additional reasons like programmatically changing styles.

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

#90

Post by dorianmariefr »

toadkicker wrote: post #10
epigen wrote: post #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.

Studies show computers running less code perform faster

loop {}
Post reply on HN