You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blade exclusively uses css-in-js using styled-components for styling all its components. This adds a runtime cost to every project that uses Blade which could be avoided if Blade used an alternate styling strategy.
The most easily noticeable impact of this is the "Avoid long main-thread tasks" performance check in Lighthouse which often gets triggered by runtime css-in-js libraries in apps using client-side rendering.
Problem
Blade exclusively uses css-in-js using
styled-components
for styling all its components. This adds a runtime cost to every project that uses Blade which could be avoided if Blade used an alternate styling strategy.Chakra UI has a similar approach and explicitly mentions this trade-off in their comparison docs:
https://chakra-ui.com/getting-started/comparison#the-runtime-trade-off-%EF%B8%8F
Refer below articles for a thorough analysis of this issue:
The most easily noticeable impact of this is the "Avoid long main-thread tasks" performance check in Lighthouse which often gets triggered by runtime css-in-js libraries in apps using client-side rendering.
Related: chakra-ui/chakra-ui#859
Solution
Consider zero-runtime alternatives for styling the components, e.g. css modules, vanilla-extract, stitches, linaria, sass, etc.
The text was updated successfully, but these errors were encountered: