It's possible that Atomic CSS-style output (each declaration gets its own classname) would be better than doing hashed classes. It's not clear if this is a good idea, but it seems worth considering.
Design gotchas to watch out for: (some helpful replies to this tweet)
What do we do in the case of custom properties generated with property? What do they compile to? How do we make sure that what they compile to does not suffer from https://github.com/rtfeldman/elm-css/issues/337?
Consider #2 in http://fela.js.org/docs/introduction/Caveats.html - probably the solution is to (1) make border3 be a "mixin" that specifies borderWidth, borderColor, etc, (2) pre-resolve cascades, e.g. if I say css [ borderWidth (px 2), borderWidth (px 3), borderWidth (px 4) ] I get only one property in the output: border-width: 4px. Maybe we should do this anyway?
In the "compile to a hash" world, people can't rely on CSS classes at all for e2e testing. Great! However, in this world, classnames are predictable enough that maybe people would.
Attempting to memoize classname calculations using a Dict would almost certainly be a net loss from a perf perspective. Dict lookups take logarithmic time, whereas string concatenation is constant. So we shouldn't expect the same level of perf that Styletron's benchmarks show.
How to benchmark:
Take a large page that's using the existing output, then recompile using the version with atomic style output. Compare load times for both. At the end of the day, this matters more than microbenchmarks - all things considered, did it make the page faster or slower?
Try it with SSR as well. Wouldn't this increase downloaded HTML file size? Maybe it's fine with gzip though, if critical CSS is in
It's possible that Atomic CSS-style output (each declaration gets its own classname) would be better than doing hashed classes. It's not clear if this is a good idea, but it seems worth considering.
Design gotchas to watch out for: (some helpful replies to this tweet)
What do we do in the case of custom properties generated with
property? What do they compile to? How do we make sure that what they compile to does not suffer from https://github.com/rtfeldman/elm-css/issues/337?Consider
#2in http://fela.js.org/docs/introduction/Caveats.html - probably the solution is to (1) makeborder3be a "mixin" that specifiesborderWidth,borderColor, etc, (2) pre-resolve cascades, e.g. if I saycss [ borderWidth (px 2), borderWidth (px 3), borderWidth (px 4) ]I get only one property in the output:border-width: 4px. Maybe we should do this anyway?In the "compile to a hash" world, people can't rely on CSS classes at all for e2e testing. Great! However, in this world, classnames are predictable enough that maybe people would.
Attempting to memoize classname calculations using a
Dictwould almost certainly be a net loss from a perf perspective.Dictlookups take logarithmic time, whereas string concatenation is constant. So we shouldn't expect the same level of perf that Styletron's benchmarks show.How to benchmark:
Take a large page that's using the existing output, then recompile using the version with atomic style output. Compare load times for both. At the end of the day, this matters more than microbenchmarks - all things considered, did it make the page faster or slower?
Try it with SSR as well. Wouldn't this increase downloaded HTML file size? Maybe it's fine with gzip though, if critical CSS is in