3 ms·

I wouldn't say we're planning to not support them. They work with React 18. If they move to useInsertionEffect they'll avoid major performance issues. The writ

I wouldn't say we're planning to not support them. They work with React 18. If they move to useInsertionEffect they'll avoid major performance issues. The writing on the wall is more that we wouldn't encourage this mechanism over time because we find that <link> + inline styles have much better performance tradeoffs. Often, it's possible to implement a very similar API but statically extractable. That's great and we encourage that. But we wouldn't add a runtime helper like css() into React because we don't think this pattern scales well. Of course, we can't stop people from using it though.

tunesmith 5y ago
Thanks Dan - can you or anyone else point to something that details those performance tradeoffs in more detail? I think some of it has to do with css render-blocking when it's part of the JS.
- danabramov 5y ago
  "When to Insert <style> on The Client" in https://github.com/reactwg/react-18/discussions/110 https://github.com/reactwg/react-18/discussions/110 describes some of the issues. Does this help?
  - tunesmith 5y ago
    Yes, thanks - after reading it more in depth. :) The "Future" section especially. I don't relish rewriting a legacy codebase that relies heavily upon css-in-js, hopefully the libraries will add compatibility.
tunesmith 5y ago
I'm wondering how switching from a css-in-js library to <link> + inline styles would impact CLS. With css-in-js we have some built-in CLS protection in that I think it blocks the JS until the CSS is present, by definition. At the least, it sounds like <link> + inline styles would take more analysis effort to determine what the critical css is for any component.
- madeofpalk 5y ago
  CSS-in-JS and external <link> style sheets are not mutually exclusive. There are a few toolkits out there that let you write component-oriented CSS-in-JS, but during build will extract everything to static external style sheets.

tunesmith 5y ago

Thanks Dan - can you or anyone else point to something that details those performance tradeoffs in more detail? I think some of it has to do with css render-blocking when it's part of the JS.

danabramov 5y ago
"When to Insert <style> on The Client" in https://github.com/reactwg/react-18/discussions/110 https://github.com/reactwg/react-18/discussions/110 describes some of the issues. Does this help?
- tunesmith 5y ago
  Yes, thanks - after reading it more in depth. :) The "Future" section especially. I don't relish rewriting a legacy codebase that relies heavily upon css-in-js, hopefully the libraries will add compatibility.

tunesmith 5y ago

I'm wondering how switching from a css-in-js library to <link> + inline styles would impact CLS. With css-in-js we have some built-in CLS protection in that I think it blocks the JS until the CSS is present, by definition. At the least, it sounds like <link> + inline styles would take more analysis effort to determine what the critical css is for any component.

madeofpalk 5y ago
CSS-in-JS and external <link> style sheets are not mutually exclusive. There are a few toolkits out there that let you write component-oriented CSS-in-JS, but during build will extract everything to static external style sheets.