4 ms·

What's the advantage to this over sass modules? You have the same scoping but with better separation of concerns, that seems the superior choice.

by jf- 8y ago

rglover 8y ago
The biggest one? Not having to wrangle class names. Like the author points out here, that becomes increasingly difficult over time. Sass is wonderful (I still rely on it in some older projects), but when I'm working with JS/React, CSS-in-JS just feels smoother and tidier.
- jf- 8y ago
  Sorry but I don’t get what you mean, and I can’t see where in the article you are referring to. What do you mean by wrangling with classnames? Do you mean clashes? That’s what modules do, they scope your scss so that you don’t get clashes between components.
  - exogen 8y ago
    I'm going to assume that SASS Modules are a SASS adaptation of CSS Modules, because it seems like "modules" might have multiple meanings in the SASS world? So please tell me if this is wrong! I've used CSS Modules and enjoyed them a little bit, but they aren't as "automatic" as many CSS-in-JS solutions, for example: 1. You still need to come up with class names, they're just not the ones ultimately used in the output because of the mangling. But you are technically still coming up with them in your source code, which is a little bit of effort. 2. You still need to manually map the local/source names from the module to the DOM elements that they apply to. Basically you are keeping multiple files in sync: decide on the local/source names in the SASS files, then import those in some other file, and remember to apply all the same names in the right places. The output names will be different, again, but you still need to do this work to keep the local/source names in sync. For (1), with some CSS-in-JS approaches, you choose only a component name and the matching class name is decided automatically, so there aren't multiple files to keep in sync. With other CSS-in-JS approaches you don't even need to come up with the component names either, you just get a `css={...}` attribute and can skip any naming work altogether. For (2), with approaches like styled-components, the class names are applied to the right DOM elements automatically because they are fundamentally tied together – so you aren't writing `class={...}` everywhere, which is still necessary with CSS Modules. Not to say that SASS Modules are bad, but those are some reasons one might prefer other solutions.
    - jf- 8y ago
      Thanks for the explanation. Yes that’s correct, it’s the same concept as css modules but with scss instead of css. I have to say though that this doesn’t seem like much of an advantage - it boils down to not having to create class names and use className={...}. The other possible advantage is not having any .css/.scss files, which to me is actually a disadvantage- I quite like the separation of concerns concept, having html and js mixed together in jsx already irks me, adding styles as well is just too much! Also, with css in js I believe that pseudo elements and animations are an issue, whereas there is no problem with these with scss modules. They both seem like valid options, but for me modules wins it.
      - exogen 8y ago
        > Also, with css in js I believe that pseudo elements and animations are an issue Here you might be remembering a particular, older technique known as "inline styles." This is probably the oldest CSS-in-JS technique, and has greatly fallen out of favor. Modern CSS-in-JS doesn't use that method anymore, and can do everything that normal CSS can do (in part because it really is just generating real CSS). So pseudo elements, media queries, animations etc. are no problem. :)
  - rglover 8y ago
    Ah, wasn't aware of that existing. In that case then I suppose it's just preference. I'm sure there are other nuances but not something worth mucking with since I'm happy/productive with CiJ.
kylemh 8y ago
The big difference is with run-time styling changes when communicating with an API. We ship an application as a whitelabel where our customers define their theme through Contentful. With CSS-in-JS, converting the entire app's theme based upon XHR is trivial. Easily done in Sass env but requires tooling/work: - Automatically shipping the smallest styles per page/component. - Automatic autoprefixing - Hashed selectors (avoidance of conflicts) - Tree-shaking (no unused styles)
silviogutierrez 8y ago
I used to think this way. In reality, you're not separating concerns, you're separating technologies (CSS and HTML). Should your backend authentication code live in the same file as your billing logic? Probably not. Separate concerns. But when the concern is "a sign up component's look and feel", I see nothing wrong (anymore!) with lumping it together. In fact, I prefer it. Just my two cents.
- jf- 8y ago
  Logic, layout and style are inherently separate parts of a component. Separate concerns in other words. Ideally they should have separate definitions. This is the cleanest and most maintainable structure. The cycle seems to be to separate things clearly, then mix them back again, then separate them out again. I’ll happily skip the mixing part of this cycle. However, that said I don’t want to give the impression that I’m being proscriptive here, other developers are perfectly free to have their own preferences just as I have mine.
tracker1 8y ago
What separation of concerns? // RenderComponent.js export default props => ( <div class="foo"> <button ...>...</button> </div> ) // RenderComponent.scss .foo { button { ... } } It looks to me like your stylesheet pretty much has the exact same structure as the component/template does. When you change one, by necessity, you change the other. Don't seem to be separate concerns to me. Only separate technologies. Now, lets say you want your component's styling to adjust based on properties passed into the component... It's going to be easier, more consistent and less of a problem to make these kinds of variants with CSS in JS techniques. You can still inherent styling values directly or through theme injection.

What's the advantage to this over sass modules? You have the same scoping but with better separation of concerns, that seems the superior choice.

by jf- 8y ago

What's the advantage to this over sass modules? You have the same scoping but with better separation of concerns, that seems the superior choice.

rglover 8y ago

The biggest one? Not having to wrangle class names. Like the author points out here, that becomes increasingly difficult over time. Sass is wonderful (I still rely on it in some older projects), but when I'm working with JS/React, CSS-in-JS just feels smoother and tidier.

jf- 8y ago
Sorry but I don’t get what you mean, and I can’t see where in the article you are referring to. What do you mean by wrangling with classnames? Do you mean clashes? That’s what modules do, they scope your scss so that you don’t get clashes between components.
- exogen 8y ago
  I'm going to assume that SASS Modules are a SASS adaptation of CSS Modules, because it seems like "modules" might have multiple meanings in the SASS world? So please tell me if this is wrong! I've used CSS Modules and enjoyed them a little bit, but they aren't as "automatic" as many CSS-in-JS solutions, for example: 1. You still need to come up with class names, they're just not the ones ultimately used in the output because of the mangling. But you are technically still coming up with them in your source code, which is a little bit of effort. 2. You still need to manually map the local/source names from the module to the DOM elements that they apply to. Basically you are keeping multiple files in sync: decide on the local/source names in the SASS files, then import those in some other file, and remember to apply all the same names in the right places. The output names will be different, again, but you still need to do this work to keep the local/source names in sync. For (1), with some CSS-in-JS approaches, you choose only a component name and the matching class name is decided automatically, so there aren't multiple files to keep in sync. With other CSS-in-JS approaches you don't even need to come up with the component names either, you just get a `css={...}` attribute and can skip any naming work altogether. For (2), with approaches like styled-components, the class names are applied to the right DOM elements automatically because they are fundamentally tied together – so you aren't writing `class={...}` everywhere, which is still necessary with CSS Modules. Not to say that SASS Modules are bad, but those are some reasons one might prefer other solutions.
  - jf- 8y ago
    Thanks for the explanation. Yes that’s correct, it’s the same concept as css modules but with scss instead of css. I have to say though that this doesn’t seem like much of an advantage - it boils down to not having to create class names and use className={...}. The other possible advantage is not having any .css/.scss files, which to me is actually a disadvantage- I quite like the separation of concerns concept, having html and js mixed together in jsx already irks me, adding styles as well is just too much! Also, with css in js I believe that pseudo elements and animations are an issue, whereas there is no problem with these with scss modules. They both seem like valid options, but for me modules wins it.
    - exogen 8y ago
      > Also, with css in js I believe that pseudo elements and animations are an issue Here you might be remembering a particular, older technique known as "inline styles." This is probably the oldest CSS-in-JS technique, and has greatly fallen out of favor. Modern CSS-in-JS doesn't use that method anymore, and can do everything that normal CSS can do (in part because it really is just generating real CSS). So pseudo elements, media queries, animations etc. are no problem. :)
- rglover 8y ago
  Ah, wasn't aware of that existing. In that case then I suppose it's just preference. I'm sure there are other nuances but not something worth mucking with since I'm happy/productive with CiJ.

kylemh 8y ago

The big difference is with run-time styling changes when communicating with an API. We ship an application as a whitelabel where our customers define their theme through Contentful. With CSS-in-JS, converting the entire app's theme based upon XHR is trivial. Easily done in Sass env but requires tooling/work: - Automatically shipping the smallest styles per page/component. - Automatic autoprefixing - Hashed selectors (avoidance of conflicts) - Tree-shaking (no unused styles)

silviogutierrez 8y ago

I used to think this way. In reality, you're not separating concerns, you're separating technologies (CSS and HTML). Should your backend authentication code live in the same file as your billing logic? Probably not. Separate concerns. But when the concern is "a sign up component's look and feel", I see nothing wrong (anymore!) with lumping it together. In fact, I prefer it. Just my two cents.

jf- 8y ago
Logic, layout and style are inherently separate parts of a component. Separate concerns in other words. Ideally they should have separate definitions. This is the cleanest and most maintainable structure. The cycle seems to be to separate things clearly, then mix them back again, then separate them out again. I’ll happily skip the mixing part of this cycle. However, that said I don’t want to give the impression that I’m being proscriptive here, other developers are perfectly free to have their own preferences just as I have mine.

tracker1 8y ago

What separation of concerns? // RenderComponent.js export default props => ( <div class="foo"> <button ...>...</button> </div> ) // RenderComponent.scss .foo { button { ... } } It looks to me like your stylesheet pretty much has the exact same structure as the component/template does. When you change one, by necessity, you change the other. Don't seem to be separate concerns to me. Only separate technologies. Now, lets say you want your component's styling to adjust based on properties passed into the component... It's going to be easier, more consistent and less of a problem to make these kinds of variants with CSS in JS techniques. You can still inherent styling values directly or through theme injection.