Yes, this is another area where web components move the needle. ShadowDOM offers powerful encapsulation. Often way faster than CSS-in-JS.
-
-
Replying to @0xcda7a @justinfagnani and
This has nothing to do with what we were previously discussing. Also shadow dom doesn’t render until JS executes, making it MUCH slower.
1 reply 0 retweets 0 likes -
Every major css-in-js library has server render support
2 replies 0 retweets 0 likes -
Replying to @jescalan @justinfagnani and
Please check out this great blog post on the topic https://meowni.ca/posts/shadow-dom/ … (at least the CSS-in-JS section)
1 reply 0 retweets 0 likes -
Replying to @0xcda7a @justinfagnani and
Just did, it doesn’t discuss or argue against the fact that shadow dom is much slower than css-in-js
4 replies 0 retweets 0 likes -
This Tweet is unavailable.
-
-
Replying to @slightlylate @treshugart and
I am baffled at how this is up for debate. Static rendered CSS, vs markup & CSS that requires a JS parse to show up?
3 replies 0 retweets 0 likes -
Replying to @jescalan @treshugart and
That *might* be faster for an initial layout, but any dynamic content will likely benefit from Shadow DOM where we use a separate resolver.
1 reply 0 retweets 1 like -
Replying to @slightlylate @jescalan and
And JS parse isn't magical. If you have inline script blocks that upgrade SD for previous sibling, likely a close race.
3 replies 0 retweets 1 like
The reason SD is faster for large-ish DOMs and documents is resolver needs to consider fewer rules/nodes at resolve & apply-time.
-
-
Replying to @slightlylate @jescalan and
So a benchmark will also need to look at the scale/size/depth of documents.
1 reply 0 retweets 2 likes -
This Tweet is unavailable.
- 1 more reply
New conversation -
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.