4 ms·

There's yet to be a CSS-in-JS library that is * loads the styles before the content or markup * as fast or faster than CSS * able to have the power of modula

There's yet to be a CSS-in-JS library that is * loads the styles before the content or markup * as fast or faster than CSS * able to have the power of modularized CSS preprocessors for reducing complex styles * worth the effort. I'm not against the idea but practically every single instance it comes up it feels like programmers who don't get CSS trying to write something in what they DO understand that handles CSS so they don't have to. That's fine, and useful, but lets not pretend it's better.

fuzionmonkey 11y ago
This is simply not true. Many CSS-in-JS libraries support build or render-time extraction of CSS, which takes care of your first criterion. Many CSS-in-JS libraries also handle style modularization, often in ways arguably better than CSS preprocessors. There's a lot of variety here. I'm not sure what you mean by "faster than CSS". CSS can be fast or slow, depending on how the CSS is written. You should take a look at: https://github.com/MicheleBertoli/css-in-js https://github.com/MicheleBertoli/css-in-js
- abritinthebay 11y ago
  > build or render-time extraction of CSS Render-time is waaaay too late. The ship has sailed at that point: so no, that doesn't take care of your first point. > Many CSS-in-JS libraries also handle style modularization, often in ways arguably better than CSS preprocessors. I've yet to see one that comes even close to SASS - not even the same game let alone the same league - so agree to disagree here. > You should take a look at: https://github.com/MicheleBertoli/css-in-js https://github.com/MicheleBertoli/css-in-js I have - all it shows is that css-in-js is not a realistic competition for sensible modular CSS via something like SASS (CSS Modules, etc, good patterns).
  - tobz 11y ago
    Can you explain your rationale on the first point WRT render time being "waaaay too late"? If your app is rendered via JS, having the CSS loaded at runtime should not matter: there's no markup to affect (repaint) and the CSS will be available before your React/etc components are rendered up.
    - abritinthebay 11y ago
      > if your app is rendered by JS only if it's pure browser-side only. Which is fine I guess - at that point you've given up on rendering performance anyhow generally (especially in initial paint).
      - izym 11y ago
        How about server-side rendering?
        abritinthebay 11y ago
        Well that that point it's slower to paint with CSS-in-JS because the browser won't have the CSS until the very last thing (after asset load, after initial paint, after content load, then after script execution). Now you could extract the CSS with a build step... but at that point you've admitted the solution is poor (and/or you're not good at CSS) and are just mitigating it by producing real CSS by automation. That's fine, but it's no replacement for general good practice or domain knowledge.
        izym 11y ago
        Do you have any proof that it's slower or is it just an assumption?
a-priori 11y ago
CSS Modules, built with Webpack configured to use extract-text-plugin, will meet all those criteria.
- abritinthebay 11y ago
  CSS Modules is a CSS design pattern. Yes you chose what classes to apply to the component in the code but... you'd do that anyhow. CSS Modules is not a CSS-in-JS framework - which is what I'm talking about - it's a design pattern for CSS abstraction. That's all good, I prefer Atomic Design principles but the concept is similar.
  - talmand 11y ago
    That's the part I don't get. From the suggested articles explaining CSS Modules I see examples that are easily controlled with simple, vanilla CSS without even the need of a processor. I even see examples where they get more complicated in the SASS part to compare against and yet a simplified CSS pattern (which they even suggest at first) achieves the exact same result. It's almost like those infomercials where the problem is exaggerated to compare against the thing being marketed. I'm interested in these concepts of CSS-in-JS and I really wish the projects wouldn't fall back on such comparisons.
    - abritinthebay 11y ago
      Indeed. CSS-in-JS is solving a problem that doesn't actually exist. Or rather... only exists because many programmers refuse to learn good practice with CSS.

fuzionmonkey 11y ago

This is simply not true. Many CSS-in-JS libraries support build or render-time extraction of CSS, which takes care of your first criterion. Many CSS-in-JS libraries also handle style modularization, often in ways arguably better than CSS preprocessors. There's a lot of variety here. I'm not sure what you mean by "faster than CSS". CSS can be fast or slow, depending on how the CSS is written. You should take a look at: https://github.com/MicheleBertoli/css-in-js https://github.com/MicheleBertoli/css-in-js

abritinthebay 11y ago
> build or render-time extraction of CSS Render-time is waaaay too late. The ship has sailed at that point: so no, that doesn't take care of your first point. > Many CSS-in-JS libraries also handle style modularization, often in ways arguably better than CSS preprocessors. I've yet to see one that comes even close to SASS - not even the same game let alone the same league - so agree to disagree here. > You should take a look at: https://github.com/MicheleBertoli/css-in-js https://github.com/MicheleBertoli/css-in-js I have - all it shows is that css-in-js is not a realistic competition for sensible modular CSS via something like SASS (CSS Modules, etc, good patterns).
- tobz 11y ago
  Can you explain your rationale on the first point WRT render time being "waaaay too late"? If your app is rendered via JS, having the CSS loaded at runtime should not matter: there's no markup to affect (repaint) and the CSS will be available before your React/etc components are rendered up.
  - abritinthebay 11y ago
    > if your app is rendered by JS only if it's pure browser-side only. Which is fine I guess - at that point you've given up on rendering performance anyhow generally (especially in initial paint).
    - izym 11y ago
      How about server-side rendering?
      - abritinthebay 11y ago
        Well that that point it's slower to paint with CSS-in-JS because the browser won't have the CSS until the very last thing (after asset load, after initial paint, after content load, then after script execution). Now you could extract the CSS with a build step... but at that point you've admitted the solution is poor (and/or you're not good at CSS) and are just mitigating it by producing real CSS by automation. That's fine, but it's no replacement for general good practice or domain knowledge.
        izym 11y ago
        Do you have any proof that it's slower or is it just an assumption?

a-priori 11y ago

CSS Modules, built with Webpack configured to use extract-text-plugin, will meet all those criteria.

abritinthebay 11y ago
CSS Modules is a CSS design pattern. Yes you chose what classes to apply to the component in the code but... you'd do that anyhow. CSS Modules is not a CSS-in-JS framework - which is what I'm talking about - it's a design pattern for CSS abstraction. That's all good, I prefer Atomic Design principles but the concept is similar.
- talmand 11y ago
  That's the part I don't get. From the suggested articles explaining CSS Modules I see examples that are easily controlled with simple, vanilla CSS without even the need of a processor. I even see examples where they get more complicated in the SASS part to compare against and yet a simplified CSS pattern (which they even suggest at first) achieves the exact same result. It's almost like those infomercials where the problem is exaggerated to compare against the thing being marketed. I'm interested in these concepts of CSS-in-JS and I really wish the projects wouldn't fall back on such comparisons.
  - abritinthebay 11y ago
    Indeed. CSS-in-JS is solving a problem that doesn't actually exist. Or rather... only exists because many programmers refuse to learn good practice with CSS.