Will do.
-
-
Replying to @slightlylate
there are definitely some bad practices, want to enumerate and educate based on real usage1 reply 0 retweets 4 likes -
Replying to @threepointone @slightlylate
Also often it's hard to optimize without real world examples. I'm sure CSS-in-js could be optimized even further. We're not done here.
1 reply 0 retweets 1 like -
Replying to @kentcdodds @threepointone
Just to be *super* clear: I don't care how you write your code, only how it runs. And when it runs, it should not embed CSS as strings in JS
2 replies 2 retweets 9 likes -
Replying to @slightlylate @kentcdodds
the latter part - can you go into some detail? what are the big problems with doing so?
2 replies 0 retweets 2 likes -
Replying to @threepointone @kentcdodds
First, you double memory cost. The string is parsed in JS, interned in the V8/DOM shared string area, then *parsed again* when applied
1 reply 1 retweet 9 likes -
Which points out the second issue: double parsing, the slow way. We can't parallelize at load time because it's embedded in your script file
3 replies 0 retweets 5 likes -
Replying to @slightlylate @threepointone
True, but there are trade-offs. Maybe I only need a fraction of my CSS at load time. I can lazy load my JavaScript much easier than CSS
1 reply 0 retweets 1 like -
Replying to @kentcdodds @threepointone
That is....weird. Why is it hard to create <link> tags or style tags w/
@import dynamically?1 reply 0 retweets 0 likes -
Tooling isn't there (yet) AFAIK. Doesn't mean I couldn't be built though! Excellent point. Something to think about!
1 reply 0 retweets 1 like

Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.