11 ms·

I've never really been comfortable with the idea, as I was raised on the idea that separation of concerns is good thing. I think one of the main appealing aspe

by lwhi 5y ago

I've never really been comfortable with the idea, as I was raised on the idea that separation of concerns is good thing. I think one of the main appealing aspects is the idea of never having a styling conflict with other components ever. Less macro-level management and organisation required. -- Edit: sorry, just realised you're talking about a specific implementation.

stevebmark 5y ago
CSS and Javascript aren't concerns, they're technologies, and separation of technologies isn't a software engineering principle. "Concern" is pretty undefined in general. If anything, they're all part of the "view" concern. It's the same reason why JSX doesn't violate separation of "concerns."
- rimliu 5y ago
  Moving goalposts is not a concern either. CSS and Javascript are concerns, becaus HTML is of content/structure, CSS is for styling and JS is for behaviour. Of course somewhere along the road devs thought that HTML and CSS are to primitive to spend any time learning them properly, because of that they later found them to bee too complex and we ended up in the mess we are right now, when we try to hide the lack of understanding under multiple wraps of abstraction.
  - stevebmark 5y ago
    I don't think it's that clear cut, you can define all sorts of behavior with both HTML and CSS, and there's no semantic meaning in `<div>`, which itself changes page style due to its layout properties. I don't know what goalposts are being moved, React/css-in-js have never violated separation of concerns. After all, css-in-js produces CSS, and React produces HTML. Separation of technologies isn't a principle, but DSLs are a well established pattern.
    - lwhi 5y ago
      Is complexity a drawback?
      - stevebmark 5y ago
        What?
        lwhi 5y ago
        I believe any extra layer between intention and result will create extra complexity. CSS in JS just isn't required a lot of the time. We have more mature methodologies available.
  - vgel 5y ago
    > CSS is for styling The web has never lived up to that ideal. Sometimes you need to add a wrapper div with no semantics to make your layout work. Sometimes you need some Javascript to do a special layout CSS doesn't support or work around some other limitation. I've never seen a project that actually had meaningful "separation of concerns" based on technology, whereas almost every componentized project has at least decent separation of concerns along the component axis -- where you can drop a component into a design without thinking about it's internals at all.
    - lwhi 5y ago
      We are not living in a world of absolutes. To put it simply, being able to replace the presentation layer _easily_ is a benefit to many projects > I've never seen a project that actually had meaningful "separation of concerns" based on technology. With respect, you just need to look a little harder. I've used react libraries which are fundamentally tied to their styling, due to the fact they use CSS in JS. Applying custom styling has been more difficult than it should have been.
  - lwhi 5y ago
    I agree, I don't know why you're being downvoted.
- lwhi 5y ago
  I disagree. You're being obtuse. JavaScript is used for more than presentation.
  - deleted 5y ago
    [deleted]
tobobo 5y ago
I don't see CSS-in-JS as a rejection of separation of concerns. In fact, one of the big advantages of CSS-in-JS is that it lets you decide how best to separate your concerns. Using hand-tuned CSS will undoubtedly be the most performant option, but it leaves you with very difficult problems at the boundary of your styling and content/structure concerns. If you have even a sliver of dynamic content in your website, it will quickly become near-impossible to verify that your content and styles work together as expected, or even to verify that your class names match between your CSS and HTML. On the other hand, if you use CSS-in-JS, what you lose in performance you gain in compatibility guarantees between your concerns, regardless of how you prefer to separate. Are you putting your styles in the same files as your layout components to fully separate one feature from another? Great, you can unit test those components and be reassured that the elements are styled as expected. Are you isolating your styles to only a certain subset of components that deal directly with styling concerns? Also great—if you're using TypeScript, you can guarantee correct use of those styles at build time. For a large enough team, those guarantees really pay off. If you have lots of customers using 2G/3G networks and want to hand-roll your CSS, I commend you! For most products, I think there's a better way to make that tradeoff and your users won't mind a slightly slower experience that has fewer bugs.
- lwhi 5y ago
  If you want to replace all the styling in your project, because you've had a rebrand; I would argue that CSS in JS makes your life more difficult. If you want to share styling between your app and your website; I would also state that this process is made more difficult. If you want to create, implement and maintain an atomic design system to build in consistency and reuse .. again, more complicated that it might have been. To add to that, this article suggests that there's a performance deficit.
The_rationalist 5y ago
Css modules totally solve this without any css in js

by lwhi 5y ago

stevebmark 5y ago

CSS and Javascript aren't concerns, they're technologies, and separation of technologies isn't a software engineering principle. "Concern" is pretty undefined in general. If anything, they're all part of the "view" concern. It's the same reason why JSX doesn't violate separation of "concerns."

rimliu 5y ago
Moving goalposts is not a concern either. CSS and Javascript are concerns, becaus HTML is of content/structure, CSS is for styling and JS is for behaviour. Of course somewhere along the road devs thought that HTML and CSS are to primitive to spend any time learning them properly, because of that they later found them to bee too complex and we ended up in the mess we are right now, when we try to hide the lack of understanding under multiple wraps of abstraction.
- stevebmark 5y ago
  I don't think it's that clear cut, you can define all sorts of behavior with both HTML and CSS, and there's no semantic meaning in `<div>`, which itself changes page style due to its layout properties. I don't know what goalposts are being moved, React/css-in-js have never violated separation of concerns. After all, css-in-js produces CSS, and React produces HTML. Separation of technologies isn't a principle, but DSLs are a well established pattern.
  - lwhi 5y ago
    Is complexity a drawback?
    - stevebmark 5y ago
      What?
      - lwhi 5y ago
        I believe any extra layer between intention and result will create extra complexity. CSS in JS just isn't required a lot of the time. We have more mature methodologies available.
- vgel 5y ago
  > CSS is for styling The web has never lived up to that ideal. Sometimes you need to add a wrapper div with no semantics to make your layout work. Sometimes you need some Javascript to do a special layout CSS doesn't support or work around some other limitation. I've never seen a project that actually had meaningful "separation of concerns" based on technology, whereas almost every componentized project has at least decent separation of concerns along the component axis -- where you can drop a component into a design without thinking about it's internals at all.
  - lwhi 5y ago
    We are not living in a world of absolutes. To put it simply, being able to replace the presentation layer _easily_ is a benefit to many projects > I've never seen a project that actually had meaningful "separation of concerns" based on technology. With respect, you just need to look a little harder. I've used react libraries which are fundamentally tied to their styling, due to the fact they use CSS in JS. Applying custom styling has been more difficult than it should have been.
- lwhi 5y ago
  I agree, I don't know why you're being downvoted.
lwhi 5y ago
I disagree. You're being obtuse. JavaScript is used for more than presentation.
- deleted 5y ago
  [deleted]

tobobo 5y ago

I don't see CSS-in-JS as a rejection of separation of concerns. In fact, one of the big advantages of CSS-in-JS is that it lets you decide how best to separate your concerns. Using hand-tuned CSS will undoubtedly be the most performant option, but it leaves you with very difficult problems at the boundary of your styling and content/structure concerns. If you have even a sliver of dynamic content in your website, it will quickly become near-impossible to verify that your content and styles work together as expected, or even to verify that your class names match between your CSS and HTML. On the other hand, if you use CSS-in-JS, what you lose in performance you gain in compatibility guarantees between your concerns, regardless of how you prefer to separate. Are you putting your styles in the same files as your layout components to fully separate one feature from another? Great, you can unit test those components and be reassured that the elements are styled as expected. Are you isolating your styles to only a certain subset of components that deal directly with styling concerns? Also great—if you're using TypeScript, you can guarantee correct use of those styles at build time. For a large enough team, those guarantees really pay off. If you have lots of customers using 2G/3G networks and want to hand-roll your CSS, I commend you! For most products, I think there's a better way to make that tradeoff and your users won't mind a slightly slower experience that has fewer bugs.

lwhi 5y ago
If you want to replace all the styling in your project, because you've had a rebrand; I would argue that CSS in JS makes your life more difficult. If you want to share styling between your app and your website; I would also state that this process is made more difficult. If you want to create, implement and maintain an atomic design system to build in consistency and reuse .. again, more complicated that it might have been. To add to that, this article suggests that there's a performance deficit.

The_rationalist 5y ago

Css modules totally solve this without any css in js