4 ms·

I've worked on and off with React since its inception, and the main reason I would use it is simple ergonomics. If you are working with an MVP or a small widget

I've worked on and off with React since its inception, and the main reason I would use it is simple ergonomics. If you are working with an MVP or a small widget project, you gain a lot of velocity. You don't need to worry about scoping, naming collisions, class toggles, etc. and as long as you use decently small components, it all fits snuggly in the same file as the component definition. The price you pay comes in the way of performance and maintainability. Since the line becomes very blurry between styling and markup, it's up to the dev(s) to bring order to potential chaos. For any bigger project, my go to solution is SCSS modules. It's by far the most versatile solution I've tried if you want to roll your own CSS and not rely on a CSS framework. You don't need to worry about scoping, the bundle process is excellent, you have access to all of your normal SCSS shenanigans and most important it's a solution that makes it dead easy to collect or break down parts into logical units.

Kiro 5y ago
I've found it easier to maintain CSS-in-JS since I know exactly what will be affected when I change it. I'm always scared to touch the .css files on large projects. I haven't used SCSS modules though.
- mekkkkkk 5y ago
  With my preferred SCSS module setup you get a hybrid solution with the best of both worlds. You can keep a clean stylesheet next to your component and then just: import { mainGraphic } from './component.scss'; [...] return ( <figure className={mainGraphic} /> ); Where `mainGraphic` is a regular class block in the SCSS. So it's pretty straight forward and the mapping is still fairly tight. At bundle time, the class name is minimized, deduped and a hash is added to it that corresponds to the rule content. The generated standalone CSS file also gets hashed for cache busting purposes. It's pretty neat. And since it's SCSS you can keep constants, mixins, functions, etc. imported and organized within and between SCSS files, separated from the components.

Kiro 5y ago

I've found it easier to maintain CSS-in-JS since I know exactly what will be affected when I change it. I'm always scared to touch the .css files on large projects. I haven't used SCSS modules though.

mekkkkkk 5y ago
With my preferred SCSS module setup you get a hybrid solution with the best of both worlds. You can keep a clean stylesheet next to your component and then just: import { mainGraphic } from './component.scss'; [...] return ( <figure className={mainGraphic} /> ); Where `mainGraphic` is a regular class block in the SCSS. So it's pretty straight forward and the mapping is still fairly tight. At bundle time, the class name is minimized, deduped and a hash is added to it that corresponds to the rule content. The generated standalone CSS file also gets hashed for cache busting purposes. It's pretty neat. And since it's SCSS you can keep constants, mixins, functions, etc. imported and organized within and between SCSS files, separated from the components.