Paradigms that CSS-in-JS introduces can be intimidating. Especially from a taditional perspective of the way we look at HTML, CSS and JavaScript.
Before, we used HTML, CSS, JavaScript as both input and output. We built layers of abstraction such as Sass for CSS. We generated HTML using backends in various flavours (PHP, Ruby, Python).
Ideas like BEM, OOCSS, SMACSS and Atomic CSS was crucial for driving the movement towards reusability. CSS architecture was treaded by the community as a serious consideration. It helped front-end teams scale in a way that's safe, easy to extend, easy to conceptualise.
Building scalable web applications, thinking in components can be a fantastic thing for web teams. Having styles coupled to components, as opposed to having them cascade down based on classes, IDs and element type does break a lot of the ways we've been writing CSS over the last ~5+ years.
The question is, how do we install systematic design principles without the structure we've been using to write our scalable CSS?
Stuff like variables, mixins and reusable visual style rules are all achievable with CSS-in-JS.
The big paradigm shift that's needed to grok the concept, is to understand that by having the input of HTML, JS, CSS written in a single language/place, we can be more deliberate how we express the relationship between styling, markup and logic.
We are starting to see people build projects to attempt to add some structure to how we do CSS in the new world of front-end, and Brad has a lot to add to this discussion given his incredible contributions to CSS over the years.
Given how expressive CSS-in-JS has made me able to express the relationship between styles, I'm not sure I'd want to go back to a world where the considerations are separated. JavaScript as a layer of abstraction can do more good than harm.
TL;DR
Layers of abstraction (i.e. Sass and now CSS-in-JS) increase ability to express front-end/design architecture. Separation of concerns by intention rather than language.
Before, we used HTML, CSS, JavaScript as both input and output. We built layers of abstraction such as Sass for CSS. We generated HTML using backends in various flavours (PHP, Ruby, Python).
Ideas like BEM, OOCSS, SMACSS and Atomic CSS was crucial for driving the movement towards reusability. CSS architecture was treaded by the community as a serious consideration. It helped front-end teams scale in a way that's safe, easy to extend, easy to conceptualise.
Building scalable web applications, thinking in components can be a fantastic thing for web teams. Having styles coupled to components, as opposed to having them cascade down based on classes, IDs and element type does break a lot of the ways we've been writing CSS over the last ~5+ years.
The question is, how do we install systematic design principles without the structure we've been using to write our scalable CSS?
Stuff like variables, mixins and reusable visual style rules are all achievable with CSS-in-JS.
The big paradigm shift that's needed to grok the concept, is to understand that by having the input of HTML, JS, CSS written in a single language/place, we can be more deliberate how we express the relationship between styling, markup and logic.
We are starting to see people build projects to attempt to add some structure to how we do CSS in the new world of front-end, and Brad has a lot to add to this discussion given his incredible contributions to CSS over the years.
Given how expressive CSS-in-JS has made me able to express the relationship between styles, I'm not sure I'd want to go back to a world where the considerations are separated. JavaScript as a layer of abstraction can do more good than harm.
TL;DR
Layers of abstraction (i.e. Sass and now CSS-in-JS) increase ability to express front-end/design architecture. Separation of concerns by intention rather than language.