3 ms·

Into actual css files or just <style> tags? It’s kind of the same idea, you scope down to such a granular level that the style literally applies to that one ele

Into actual css files or just <style> tags? It’s kind of the same idea, you scope down to such a granular level that the style literally applies to that one element. It bypasses CSS and forces style composition to occur at a programmatic level (Component-first thinking). It’s one thing to utilize the convenience of css-in-js as needed, but we have, as usual, gone to the extreme and just wholesale ditched css lol.

hunterb123 5y ago
It depends, some solutions generate atomic css, some normal css rules, and a couple generate inline styles. CSS-in-JS is similar to React abstracting away HTML, as well as solving global issues etc. React Native Web abstracts both the view and style layer, you work with a RN stylesheet based interface that generates atomic css on web and RN stylesheets on native. Similar to how React generates HTML on web and native controls on other platforms. Personally CSS is too bloated, I love working with a subset that includes flexbox and the core styling properties.
have_faith 5y ago
> Into actual css files or just <style> tags? Either, it depends on the library. It's becoming more popular to extract into regular css files as opposed to style tags. This is usually referred to as 'zero runtime css-in-js' as it doesn't depend on any JS for styles to load but you still get the composability and benefits of writing it in js. > you scope down to such a granular level that the style literally applies to that one element. It applies to that component (and any instance of that component), css-in-js also supports all standard css composition so it's very easy to do something like target all spans tags inside FancyButtons, you don't only have to target components. At the end of the day it's a superset of css, all normal css is valid so no css has been ditched. This has come about because css requires you to manually keep styles and components in sync and css-in-js couples them together in a way that removes that management while also making it impossible to accidentally cause conflicts e.g. multiple components defining their own Container will never touch each others css unless you explitly import that definition and use it. I have nothing against regular css and I'm a big fan of SCSS and CSS modules but css-in-js has a lot of advantages.

hunterb123 5y ago

It depends, some solutions generate atomic css, some normal css rules, and a couple generate inline styles. CSS-in-JS is similar to React abstracting away HTML, as well as solving global issues etc. React Native Web abstracts both the view and style layer, you work with a RN stylesheet based interface that generates atomic css on web and RN stylesheets on native. Similar to how React generates HTML on web and native controls on other platforms. Personally CSS is too bloated, I love working with a subset that includes flexbox and the core styling properties.

have_faith 5y ago

> Into actual css files or just <style> tags? Either, it depends on the library. It's becoming more popular to extract into regular css files as opposed to style tags. This is usually referred to as 'zero runtime css-in-js' as it doesn't depend on any JS for styles to load but you still get the composability and benefits of writing it in js. > you scope down to such a granular level that the style literally applies to that one element. It applies to that component (and any instance of that component), css-in-js also supports all standard css composition so it's very easy to do something like target all spans tags inside FancyButtons, you don't only have to target components. At the end of the day it's a superset of css, all normal css is valid so no css has been ditched. This has come about because css requires you to manually keep styles and components in sync and css-in-js couples them together in a way that removes that management while also making it impossible to accidentally cause conflicts e.g. multiple components defining their own Container will never touch each others css unless you explitly import that definition and use it. I have nothing against regular css and I'm a big fan of SCSS and CSS modules but css-in-js has a lot of advantages.