Revisiting the Rendering Tier
theguardian.com
theguardian.com
Am I wrong?
Edit: whoops, didn't realize you were talking about styling, not functionality.
The core idea isn't strictly to generate CSS from JavaScript per se, but to generate CSS in whatever code is generating your HTML. In React, that's JS, but if you're generating HTML server-side in PHP or Ruby, the argument calls for generating CSS in PHP or Ruby.
vjeux's talk identifies seven problems:
1) global namespace: CSS has a page-global namespace for classes
2) dependency management: if you forget to include CSS, but another module/component on the page includes the CSS you need, your code will seem to work, until they remove their dependency and your code will magically break
3) dead code elimination: you can't know whether a CSS rule can be removed unless/until you can prove that the HTML generator won't generate any HTML that matches its selector, which can be impossible in the general case
4) minification: you can't minify class names without coordinating with the HTML generator
5) sharing constants: "padding: 5px" has to be kept in sync with the HTML generator "buttonPadding = 5"
6) non-deterministic resolution: loading CSS files in a different order results in different rules with the same specificity winning ties
7) isolation: component clients can use CSS to style the internals of an element, making the HTML structure implicitly part of a component's API
vjeux calls for applying generated styles as inline styles with the "style" attribute, primarily because it's straightforward to implement. You may be able to get better performance by generating a <style> tag on the server side, or extracting a CSS file from the HTML generator instead.
Beware that if you're generating your HTML only in client-side JS, that can be bad for performance, and CSS-in-JS is likely to make that worse. At least run your JS on the server side, so you can send HTML + CSS to the client on first load.
You are definitely right that there are still challenges around how you structure and re-use JSX components.
However, our primary motivation with CSS-in-JS was to achieve decoupling between different parts of the page when it comes to CSS. I.e. if I change this part of page A, will I break other parts of the page? Or even, will I break something on a completely different page? By scoping styles to components, CSS-in-JS helps avoid these kinds of issues. Of course, it introduces its own complexities.
This is really not an academic concern on a large website with daily commits by developers often from different teams and not necessarily experts in CSS. Only last week I had to fix an issue of this kind.
I agree entirely with 'scoping styles to components' but css in js is a massive step backwards when this can be accomplished much more simply by maintaining a less / sass / css file in the same folder as the js and importing it.
My two cents, as a contractor who is paid to fix other people's code: there is an aspect to semantic HTML which is the descriptive nature of attribute class names. This is completely destroyed by css-in-js.
In short: I can easily track down the styling (and probably the component) in the code based on an attribute classname. How on earth do I do that when every single class is named some combination of 'R23RG67ED'? I know there are things you can do in Webpack to create some sort of descriptive name ('component_1-wrapper_2-div_3-my_wacky_component_5-GEWRCER anyone?) but a) nobody does this and b) if the only reason we're implementing css-in-js is for issues of scope, surely this is not a step forward?
Edit: just to add, the comment in this thread https://news.ycombinator.com/item?id=19608498 does a much better job of explaining all the benefits of CSS-in-JS.