4 ms·

What do you mean with "the usual way"? ;) There is vanilla CSS, Sass, CSS modules, Aphrodite, Radium, JSS,… This image from the talk I just gave about it sums

by mxstbr 10y ago

What do you mean with "the usual way"? ;) There is vanilla CSS, Sass, CSS modules, Aphrodite, Radium, JSS,… This image from the talk I just gave about it sums the differences up quite well: http://imgur.com/dmiROz6.jpg http://imgur.com/dmiROz6.jpg You can also see a comparison with other styling methods here: https://github.com/styled-components/comparison https://github.com/styled-components/comparison (this is where the checklists are from)

madeofpalk 10y ago
Interesting. What warrants a for CSS Modules co-location? Is it just because you can't write it in the same JS file as your component? I'm also super duper skeptical of style interoperability between React Native and the browser. From experience styling in React Native suffers from the uncanny valley - its so close to browser CSS, but ends up failing in rather significant ways (mainly layout) that would prevent style reuse.
- mxstbr 10y ago
  Yes exactly. It's less about interoperability and more about using the same styling system for_all_ parts of your application. Styling on ReactNative is different enough to have to be careful when doing it, though theoretically it's very possible.
pluma 10y ago
Note that while CSS modules doesn't provide an out-of-the-box solution for themeing you can use css variables and then either just swap out the variables (if you only target browsers that support the custom properties spec) or run the CSS through postCSS. The important difference however is that CSS-in-JS can swap out themes on the fly whereas this would be a static solution that doesn't scale e.g. if you need per-user customization.
- mxstbr 10y ago
  > if you only target browsers that support the custom properties spec That "sidenote" is exactly why vanilla CSS has a "Kinda" for theming. Taking a look at caniuse[0], only 66.39% of browsers have support for custom properties – not exactly production ready. That being said, once custom properties are well supported they're an amazing solution for theming! Take a look at this talk Glen (the co-creator of CSS modules and now styled-components) gave at JSConf BP for some hints towards this future: https://www.youtube.com/watch?v=XR6eM_5pAb0 https://www.youtube.com/watch?v=XR6eM_5pAb0 [0]: http://caniuse.com/#feat=css-variables http://caniuse.com/#feat=css-variables
  - pluma 10y ago
    IMO PostCSS is a workable solution until that number gets closer to 100%. It just requires the aforementioned post-processing step per theme to "render" the stylesheet with the correct variables: https://github.com/postcss/postcss-custom-properties https://github.com/postcss/postcss-custom-properties
ioseph 10y ago
Sorry just realised my question wasn't clear at all By usual way I mean using inline styles the React way i.e. style={_componentStyle}
- mxstbr 10y ago
  The huge downside with inline styles is that they don't support all of CSS _at all_. You have to reimplement basic things like pseudo selectors (hover/active/focussed/… styles) and things like pseudo elements, media queries, keyframes are non-existant. On top of that, for the eventual global style you need (e.g. @font-face) you now have to add a separate build step for actual CSS to add that. We have a language on the web that's made for styling. It has support for all those things by default. It's called CSS. Why not use it?

by mxstbr 10y ago

madeofpalk 10y ago

Interesting. What warrants a for CSS Modules co-location? Is it just because you can't write it in the same JS file as your component? I'm also super duper skeptical of style interoperability between React Native and the browser. From experience styling in React Native suffers from the uncanny valley - its so close to browser CSS, but ends up failing in rather significant ways (mainly layout) that would prevent style reuse.

mxstbr 10y ago
Yes exactly. It's less about interoperability and more about using the same styling system for_all_ parts of your application. Styling on ReactNative is different enough to have to be careful when doing it, though theoretically it's very possible.

pluma 10y ago

Note that while CSS modules doesn't provide an out-of-the-box solution for themeing you can use css variables and then either just swap out the variables (if you only target browsers that support the custom properties spec) or run the CSS through postCSS. The important difference however is that CSS-in-JS can swap out themes on the fly whereas this would be a static solution that doesn't scale e.g. if you need per-user customization.

mxstbr 10y ago
> if you only target browsers that support the custom properties spec That "sidenote" is exactly why vanilla CSS has a "Kinda" for theming. Taking a look at caniuse[0], only 66.39% of browsers have support for custom properties – not exactly production ready. That being said, once custom properties are well supported they're an amazing solution for theming! Take a look at this talk Glen (the co-creator of CSS modules and now styled-components) gave at JSConf BP for some hints towards this future: https://www.youtube.com/watch?v=XR6eM_5pAb0 https://www.youtube.com/watch?v=XR6eM_5pAb0 [0]: http://caniuse.com/#feat=css-variables http://caniuse.com/#feat=css-variables
- pluma 10y ago
  IMO PostCSS is a workable solution until that number gets closer to 100%. It just requires the aforementioned post-processing step per theme to "render" the stylesheet with the correct variables: https://github.com/postcss/postcss-custom-properties https://github.com/postcss/postcss-custom-properties

ioseph 10y ago

Sorry just realised my question wasn't clear at all By usual way I mean using inline styles the React way i.e. style={_componentStyle}

mxstbr 10y ago
The huge downside with inline styles is that they don't support all of CSS _at all_. You have to reimplement basic things like pseudo selectors (hover/active/focussed/… styles) and things like pseudo elements, media queries, keyframes are non-existant. On top of that, for the eventual global style you need (e.g. @font-face) you now have to add a separate build step for actual CSS to add that. We have a language on the web that's made for styling. It has support for all those things by default. It's called CSS. Why not use it?