I think this is largely a leftover from the old days of web development. With react and other component based frameworks there isn't really any benefit to separating logic and styles
#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
React is at it's best with very interactive and dynamic interfaces, yet many use it to render mostly static sites where most of React's way to work as a single tree becomes a burden due to performance issues, and growing bundle sizes. Code splitting to multiple bundles is more of a workaround and a sign of an issue than a solution. User still needs to get all the data. JS execution is also expensive as a simple React app takes longer to complete first render than it takes to render a multimegabyte HTML without JS.
If you consider using more than one library/framework in a project and instead of building a monolith bundle you use a tool best fit for a specific task at hand then CSS-in-JS can be quite inflexible as sharing styles between multiple frameworks becomes an issue. You want to avoid unnecessary duplication.
If there are multiple projects that share a common style it makes much more sense to provide it in CSS than force a single CSS-in-JS solution on everyone, because JS libraries and tools come and go, but CSS stays. Devs love to have a go with new tools every now and then.
Then there is the fact for some parts of a site using vanilla JS can work very well. Not everyone likes this idea as there seem to be people who think everything has to go through a single solution and follow the one chosen thing. Even when it is ill-fitted to whatever is the task to be done.
So there is value in separation when aiming for a well performing site. The less runtime logic you have running the better.
I'm afraid you misunderstood my question. I didn't ask if we should use "vanilla css" vs "css-in-js". I was talking only about CSS-in-JS approach, but within two techniques: Using a "css prop" or "styled module".
Regardless of that, thank you for your perspective. I pretty much agree with and you are saying :)
I don't agree with that at all, react is excellent for static sites as well. Especially when using a framework like Gatsby or nextJS.
Frameworks has gotten a bad rep when it comes to performance, mostly because of performance and bloated bundles, but neither is because if the framework.
Separation of logic and styles is a good idea. You can name styled Item component as an ItemWrapper for better readability.
I think this is largely a leftover from the old days of web development. With react and other component based frameworks there isn't really any benefit to separating logic and styles
React is at it's best with very interactive and dynamic interfaces, yet many use it to render mostly static sites where most of React's way to work as a single tree becomes a burden due to performance issues, and growing bundle sizes. Code splitting to multiple bundles is more of a workaround and a sign of an issue than a solution. User still needs to get all the data. JS execution is also expensive as a simple React app takes longer to complete first render than it takes to render a multimegabyte HTML without JS.
If you consider using more than one library/framework in a project and instead of building a monolith bundle you use a tool best fit for a specific task at hand then CSS-in-JS can be quite inflexible as sharing styles between multiple frameworks becomes an issue. You want to avoid unnecessary duplication.
If there are multiple projects that share a common style it makes much more sense to provide it in CSS than force a single CSS-in-JS solution on everyone, because JS libraries and tools come and go, but CSS stays. Devs love to have a go with new tools every now and then.
Then there is the fact for some parts of a site using vanilla JS can work very well. Not everyone likes this idea as there seem to be people who think everything has to go through a single solution and follow the one chosen thing. Even when it is ill-fitted to whatever is the task to be done.
So there is value in separation when aiming for a well performing site. The less runtime logic you have running the better.
I'm afraid you misunderstood my question. I didn't ask if we should use "vanilla css" vs "css-in-js". I was talking only about CSS-in-JS approach, but within two techniques: Using a "css prop" or "styled module".
Regardless of that, thank you for your perspective. I pretty much agree with and you are saying :)
I don't agree with that at all, react is excellent for static sites as well. Especially when using a framework like Gatsby or nextJS.
Frameworks has gotten a bad rep when it comes to performance, mostly because of performance and bloated bundles, but neither is because if the framework.
Could you further explain the benefits of "separation of logic and styles". Where exactly styled is better than css prop in that matter?