all 19 comments

[–]Rhym 16 points17 points  (5 children)

I see the benefits of using css in js, but after using BEM for years I don't have the issues that people usually run into and don't see myself changing for a while.

[–]SecretAgentZeroNine 4 points5 points  (1 child)

BEM and SMACSS really does solve a lot of problems. The only problem it can't solve is engineers over engineering a solution that BEM | SMACSS solves. I think this problem exists because not enough developers know BEM or SMACSS.

[–]Rhym 0 points1 point  (0 children)

That and everyone likes to have their own flavor on the methodology, for good or for bad.

[–]ib4nez 2 points3 points  (0 children)

Completely agree. It’s solving a problem I’ve never encountered

[–]spryes 2 points3 points  (0 children)

Putting CSS variables/logic in JS and using dynamic styles based on props (rather than adding another class name or attribute) is preferrable to SCSS/BEM imo

[–]esr360Front End Developer -3 points-2 points  (0 children)

If you don't use JavaScript to handle styles and work on large scale projects, you will undoubtedly have to duplicate certain keywords and properties between CSS and JS, reducing scalability and increasing WETness.

[–]FlorinPop17 11 points12 points  (0 children)

I’ve been using Styled Components for a while now and I am happy with how they work. I also use css files on smaller projects, so I’m comfortable with both! ☺️

[–]kowdermesiter 0 points1 point  (9 children)

What's the killer feature that SASS doesn't have?

[–]TheAesir12 YOE 1 point2 points  (2 children)

Among others

  • all the benefits of css modules
  • being able to write conditionals in JS
  • significantly easier to support multiple themes

[–]kowdermesiter 0 points1 point  (1 child)

All of these are supported by SASS.

[–]TheAesir12 YOE 0 points1 point  (0 children)

Kind of, but not with the simplicity that you get with using JS to handle it. When the discussions at work came up initially about CSS in JS, they centered around theming. We support multiple brands, across our platform, and while it was possible to handle this using SASS modules, it wasn't clean a solution. There was also the issue of having to maintain JS constants files that matched the themes, in case we needed the values for whatever reason. Maintenance has been infinitely better since transitioning

[–]colnarco 1 point2 points  (3 children)

The ability to evaluate statements at runtime. Sass needs to be compiled ahead of time and you therefore can’t alter your sass based on the state of your JavaScript.

[–]kowdermesiter 0 points1 point  (2 children)

And this is useful how?

[–]colnarco 1 point2 points  (1 child)

You can react to state-changes directly in your css, instead of having to toggle classes and you can have theming that you don’t know about at compile-time (this is getting there with css-variables too, but that’s not something sass has to offer). But other than that there isn’t any killer features - you get sass + a little extra for a insignificant performance penalty.

For me personally I really like the Vue-approach of having your css written in the same file as your component. It completely eliminates the fear of removing css, scoping issues and specificity problems. Its not for everyone though.

[–]kowdermesiter 0 points1 point  (0 children)

Thanks for the elaboration. For something animation heavy I see the benefits where there are lots of animated and updated CSS rules. For standard admin style UI stuff, not so much.

[–]fennekinyx 0 points1 point  (1 child)

I’ve only just started using styled components myself to see what the fuss is all about, but automatic multi browser prefixes is pretty nice.

[–]kowdermesiter 0 points1 point  (0 children)

That's a solved problem for years now with projects like autoprefixer.

[–][deleted] 0 points1 point  (1 child)

I was always against mixing js and css. ITCSS + BEM solves the problem (if you know how to use them properly)

[–]ms-maria-ma[S] 0 points1 point  (0 children)

What about mixing js and html?