4 ms·

What do you think is so painful about styling in React? Genuinely curious. The scoping of stuff? The organization?

Klathmon 9y ago
There are basically 3 options, and they all have really big downsides: * CSS modules - can use any CSS preprocessors, fast, can be extracted into CSS files, but it's very hard to "theme" and very hard to style/modify 3rd party components. * Css-in-js - uses Js to render, using preprocessors is much more difficult, can't easily extract into CSS files, somewhat easier to theme and share. * Inline styles - even slower, harder to preprocess, harder to extract, but very easy to theme and override. And all 3 don't work well with one another. So if you get a widget made with inline styles, overriding the color is hard with CSS modules...
- jefflombardjr 9y ago
  Thanks for your perspective! Don't know if you've seen this, I've been toying with this approach: https://www.youtube.com/watch?v=bIK2NwoK9xk https://www.youtube.com/watch?v=bIK2NwoK9xk , and like the fact that you're writing css, even though it's technically css-in-js.
- bsimpson 9y ago
  Isn't the whole point of CSS-in-JS that you don't need a toy language to do preprocessing if you have a real language like JavaScript? I haven't really used SASS et. al., but my understanding is that they were hacks to get shared constants, functions, and derived values in a CSS that predated custom properties.
  - Klathmon 9y ago
    But with the downside of basically replicating a lot of what the CSS engine does in Javascript, further polluting the already stressed "main" thread in many JS applications. And doing it in a slower, less battery efficient, and less cacheable way. And in my opinion, a language like SASS isn't a "hack" but is a very specific and extremely powerful language which is dedicated to one use (styling) and therefore most styling-specific code is very natural with SASS, however with JS it gets more difficult (want to extend another style defined elsewhere? You kind of need to work with JS that wasn't really designed to make that an easy task, in SASS it's `@extend %other-class`)

There are basically 3 options, and they all have really big downsides: * CSS modules - can use any CSS preprocessors, fast, can be extracted into CSS files, but it's very hard to "theme" and very hard to style/modify 3rd party components. * Css-in-js - uses Js to render, using preprocessors is much more difficult, can't easily extract into CSS files, somewhat easier to theme and share. * Inline styles - even slower, harder to preprocess, harder to extract, but very easy to theme and override. And all 3 don't work well with one another. So if you get a widget made with inline styles, overriding the color is hard with CSS modules...

jefflombardjr 9y ago
Thanks for your perspective! Don't know if you've seen this, I've been toying with this approach: https://www.youtube.com/watch?v=bIK2NwoK9xk https://www.youtube.com/watch?v=bIK2NwoK9xk , and like the fact that you're writing css, even though it's technically css-in-js.
bsimpson 9y ago
Isn't the whole point of CSS-in-JS that you don't need a toy language to do preprocessing if you have a real language like JavaScript? I haven't really used SASS et. al., but my understanding is that they were hacks to get shared constants, functions, and derived values in a CSS that predated custom properties.
- Klathmon 9y ago
  But with the downside of basically replicating a lot of what the CSS engine does in Javascript, further polluting the already stressed "main" thread in many JS applications. And doing it in a slower, less battery efficient, and less cacheable way. And in my opinion, a language like SASS isn't a "hack" but is a very specific and extremely powerful language which is dedicated to one use (styling) and therefore most styling-specific code is very natural with SASS, however with JS it gets more difficult (want to extend another style defined elsewhere? You kind of need to work with JS that wasn't really designed to make that an easy task, in SASS it's `@extend %other-class`)