
Revisiting the Rendering Tier - brianzelip
https://www.theguardian.com/info/2019/apr/04/revisiting-the-rendering-tier
======
et1337
I understand the struggles and problems this article lists, particularly the
"re-use or duplicate" quandary, but then I'm not sure how "CSS in JS" solves
all of them. Seems to me like the question becomes, do I re-use this React
component, or duplicate it?

Am I wrong?

~~~
dfabulich
Here's the canonical slide deck that kicked off the "CSS in JS" trend.
[https://speakerdeck.com/vjeux/react-css-in-
js](https://speakerdeck.com/vjeux/react-css-in-js)

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.

~~~
aassddffasdf
I'm surprised this is still something people talk about. I have been using
generated inline CSS for several years now.

------
hn23
This page looks like you could delete most of the style stuff...

~~~
room271
Ha yes definitely. One of our motivations in this work is to be able to
identify and serve only the CSS that is needed for the specific
page/components being requested.

